Re: [Intel-gfx] Skylake / (EE) modeset(0): present flip failed loop

Is this the right place to send this? Can anyone help? On Wed, Jul 05, 2017 at 11:33:01PM -0700, Marc MERLIN wrote: > Howdy, > > I have a thinkpad P70 with debian testing and 4.11.6 kernel. > A recent-ish upgrade broke something and now I'm getting loads of spam > in my Xorg.log > > [

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported format for sprite plane

> -Original Message- > From: Taylor, Clinton A > Sent: Friday, July 7, 2017 4:20 AM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported > format for sprite plane > > > > On

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Add NV12 support to intel_framebuffer_init

> -Original Message- > From: Taylor, Clinton A > Sent: Friday, July 7, 2017 4:26 AM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915: Add NV12 support to > intel_framebuffer_init > > > > On 06/19/2017

[Intel-gfx] [PATCH 15/15] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V5: Added r-b from

[Intel-gfx] [PATCH 12/15] drm/i915: prepare pipe for YCBCR420 output

To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full blend mode to use the scaler in 5x3 ratio (bits 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

[Intel-gfx] [PATCH 14/15] drm/i915: set colorspace for YCBCR420 outputs

When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) Cc: Ville Syrjala

[Intel-gfx] [PATCH 13/15] drm/i915: prepare csc unit for YCBCR420 output

To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler, which uses recommended bspec values to

[Intel-gfx] [PATCH 08/15] drm: set output colorspace in AVI infoframe

A source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. This patch adds a function to add the output colorspace information in the AVI infoframes. V2: Rebase V3: Rebase V4: Rebase V5: Rebase V6: Made patch independent of HDMI

[Intel-gfx] [PATCH 10/15] drm/i915: add config function for YCBCR420 outputs

This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420 output, else continue with RGB output mode. It checks if the mode is YCBCR420 and source can support this output then it marks the

[Intel-gfx] [PATCH 11/15] drm/i915: prepare scaler for YCBCR420 modeset

To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[Intel-gfx] [PATCH 07/15] drm/edid: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of

[Intel-gfx] [PATCH 04/15] drm/edid: cleanup patch for CEA extended-tag macro

CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from

[Intel-gfx] [PATCH 09/15] drm: add helper functions for YCBCR420 handling

This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling

[Intel-gfx] [PATCH 02/15] drm/edid: complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

[Intel-gfx] [PATCH 06/15] drm: add helper to validate YCBCR420 modes

YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm

[Intel-gfx] [PATCH 03/15] drm/edid: parse sink information before CEA blocks

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the

[Intel-gfx] [PATCH 05/15] drm/edid: parse YCBCR420 videomodes from EDID

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which

[Intel-gfx] [PATCH 00/15] YCBCR 4:2:0 handling in DRM layer

Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA 4K@60, RGB

[Intel-gfx] [PATCH 01/15] drm: handle HDMI 2.0 VICs in AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Gen10 render context size.

On 17-07-06 14:06:24, Vivi, Rodrigo wrote: No change on render context size is required for Gen10. So this patch doesn't change the default behaviour, but only avoid the missing_case message. Cc: Ben Widawsky Signed-off-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH i-g-t v2 2/2] tests/gem_reset_stats: Enforce full chip reset mode before run

On 06/07/17 15:50, Antonio Argenziano wrote: + +igt_fixture { +int fd; + +fd = drm_open_driver(DRIVER_INTEL); +igt_assert(igt_sysfs_set_parameter + (fd, "reset", "%d", INT_MAX /* any reset method */)); I would still suggest that we restore the reset

Re: [Intel-gfx] [PATCH i-g-t 0/5] igt/kms: Make fence waiting explicit.

Hi Maarten, 2017-07-06 Maarten Lankhorst : > I wanted to make kms_atomic_transition pass, but the nonblocking modeset > fencing tests were bogus. > > This series changes the semantics for fencing slightly. It only keeps the out > fences > in

[Intel-gfx] [PATCH 0/3] MOCS versioning

Copying the kernel commit message: Starting with GEN9, Memory Object Control State (MOCS) becomes an index into a table as opposed to the direct programming within the command. The table has 62 usable entries (ie 6 bits can represent all settings), and each buffer type may use one of these 62

[Intel-gfx] [PATCH 1/1] drm/i915: Version the MOCS settings

From: Ben Widawsky Starting with GEN9, Memory Object Control State (MOCS) becomes an index into a table as opposed to the direct programming within the command. The table has 62 usable entries (ie 6 bits can represent all settings), and each buffer type may use one

[Intel-gfx] [PATCH 3/3] intel: Make driver aware of MOCS table version

We don't yet have optimal MOCS settings, but we have enough to know how to at least determine when we might have non-optimal settings within our driver. Signed-off-by: Ben Widawsky --- src/intel/vulkan/anv_device.c | 12 src/intel/vulkan/anv_private.h

[Intel-gfx] [PATCH 2/3] intel: Merge latest i915 uapi

Signed-off-by: Ben Widawsky --- src/intel/drm/i915_drm.h | 8 1 file changed, 8 insertions(+) diff --git a/src/intel/drm/i915_drm.h b/src/intel/drm/i915_drm.h index c26bf7c125..69e38ce89f 100644 --- a/src/intel/drm/i915_drm.h +++ b/src/intel/drm/i915_drm.h @@ -431,6

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Gen10 render context size.

== Series Details == Series: drm/i915/cnl: Gen10 render context size. URL : https://patchwork.freedesktop.org/series/26955/ State : success == Summary == Series 26955v1 drm/i915/cnl: Gen10 render context size. https://patchwork.freedesktop.org/api/1.0/series/26955/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Cannonlake color init.

merged to dinq. thanks for the review. On Thu, Jul 6, 2017 at 2:46 PM, Clint Taylor wrote: > > Reviewed-by: Clinton Taylor > > -Clint > > > On 07/06/2017 02:01 PM, Rodrigo Vivi wrote: >> >> Cannonlake has same color setup as Geminilake. >>

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for x86/gpu: CNL uses the same GMS values as SKL

Merged to dinq. On Wed, Jul 5, 2017 at 6:32 PM, Patchwork wrote: > == Series Details == > > Series: x86/gpu: CNL uses the same GMS values as SKL > URL : https://patchwork.freedesktop.org/series/26880/ > State : success > > == Summary == > > Series 26880v1

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add force wake for gen10+.

Merged to dinq. Thanks for review. On Wed, Jul 5, 2017 at 6:00 PM, Rodrigo Vivi wrote: > By spec there is no change on force wake registers > for Cannonlake. Let's reuse gen9 one. > > v2: Adding missing case for the write part. (Tvrtko) > v3: Rebase on recent tree. > v4:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Enable Audio Pin Buffer.

== Series Details == Series: drm/i915/cnl: Enable Audio Pin Buffer. URL : https://patchwork.freedesktop.org/series/26954/ State : success == Summary == Series 26954v1 drm/i915/cnl: Enable Audio Pin Buffer. https://patchwork.freedesktop.org/api/1.0/series/26954/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Add NV12 support to intel_framebuffer_init

On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch adds NV12 as supported format to intel_framebuffer_init and performs various checks. v2: -Fix an issue in checks added (Chandra Konduru) v3: rebased (me) v4: Review comments by Ville

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Cannonlake color init.

== Series Details == Series: drm/i915/cnl: Cannonlake color init. URL : https://patchwork.freedesktop.org/series/26953/ State : success == Summary == Series 26953v1 drm/i915/cnl: Cannonlake color init. https://patchwork.freedesktop.org/api/1.0/series/26953/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH i-g-t v2 2/2] tests/gem_reset_stats: Enforce full chip reset mode before run

On 28/06/17 11:37, Michel Thierry wrote: Platforms with per-engine reset enabled (i915.reset=2) are unlikely to perform a full chip reset, keeping the reset_count unmodified. In order to keep the expectations of this test, enforce that full GPU reset is enabled (i915.reset=1). Later on, we

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported format for sprite plane

On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch adds NV12 to list of supported formats for sprite plane. v2: Rebased (me) v3: Review comments by Ville addressed - Removed skl_plane_formats_with_nv12 and added NV12

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add NV12 as supported format for primary plane

On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch adds NV12 to list of supported formats for primary plane v2: Rebased (Chandra Konduru) v3: Rebased (me) v4: Review comments by Ville addressed Removed the

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Upscale scaler max scale for NV12

On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch updates scaler max limit support for NV12 v2: Rebased (me) Needs rebase again. Tested-by: Clinton Taylor Reviewed-by: Clinton Taylor

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/cnl: Add allowed DP rates for Cannonlake.

== Series Details == Series: series starting with [1/3] drm/i915/cnl: Add allowed DP rates for Cannonlake. URL : https://patchwork.freedesktop.org/series/26952/ State : success == Summary == Series 26952v1 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

On Thu, 2017-07-06 at 16:14 +0300, Paul Kocialkowski wrote: > On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote: > > So a couple of notes here that will make it a lot easier for me to > > review these in the future > > > >  * When you're doing a new revision of a patch series, it's helpful > >

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Update format_is_yuv() to include NV12

On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch adds NV12 to format_is_yuv() function and made it available for both primary and sprite planes small nit on the commit message: static function in intel_sprite.c is not available

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Set scaler mode for NV12

Tested-by: Clinton Taylor Reviewed-by: Clinton Taylor -Clint On 06/19/2017 11:10 PM, Vidya Srinivas wrote: From: Chandra Konduru This patch sets appropriate scaler mode for NV12 format. In this mode,

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

On Thu, 2017-07-06 at 14:35 +0300, Paul Kocialkowski wrote: > On Thu, 2017-07-06 at 10:41 +0300, Martin Peres wrote: > > On 06/07/17 00:44, Lyude Paul wrote: > > > On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > > > > When a CRC comparison error occurs, it is quite useful to get a >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Get DDI clock based on PLLs.

== Series Details == Series: drm/i915/cnl: Get DDI clock based on PLLs. URL : https://patchwork.freedesktop.org/series/26950/ State : success == Summary == Series 26950v1 drm/i915/cnl: Get DDI clock based on PLLs. https://patchwork.freedesktop.org/api/1.0/series/26950/revisions/1/mbox/ Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add max allowed Cannonlake DC.

== Series Details == Series: drm/i915/cnl: Add max allowed Cannonlake DC. URL : https://patchwork.freedesktop.org/series/26949/ State : success == Summary == Series 26949v1 drm/i915/cnl: Add max allowed Cannonlake DC. https://patchwork.freedesktop.org/api/1.0/series/26949/revisions/1/mbox/

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

--snip-- (also sorry this one took a while to get to, had to do a lot of thinking because I never really solved the problems mentioned here when I tried working on this...) On Thu, 2017-07-06 at 16:33 +0300, Paul Kocialkowski wrote: > On Thu, 2017-07-06 at 14:31 +0300, Paul Kocialkowski wrote: >

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Don't trust VBT's alternate pin for port D for now.

On 07/06/2017 02:08 PM, Rodrigo Vivi wrote: Cannon Lake's VBT that is currently available for B0 stepping states that port D uses alternate pin 3 messing up with the default pin-port mapping table. Using that information we cannot get HDMI working properly. So for now we don't relly on VBT for

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Inherit RPS stuff from previous platforms.

== Series Details == Series: drm/i915/cnl: Inherit RPS stuff from previous platforms. URL : https://patchwork.freedesktop.org/series/26948/ State : success == Summary == Series 26948v1 drm/i915/cnl: Inherit RPS stuff from previous platforms.

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Cannonlake color init.

Reviewed-by: Clinton Taylor -Clint On 07/06/2017 02:01 PM, Rodrigo Vivi wrote: Cannonlake has same color setup as Geminilake. Legacy color load luts doesn't work anymore on Cannonlake+. Cc: Clint Taylor Cc: Ander Conselvan de Oliveira

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pre-g4x GPU reset, again (rev3)

== Series Details == Series: drm/i915: Fix pre-g4x GPU reset, again (rev3) URL : https://patchwork.freedesktop.org/series/26554/ State : success == Summary == Series 26554v3 drm/i915: Fix pre-g4x GPU reset, again https://patchwork.freedesktop.org/api/1.0/series/26554/revisions/3/mbox/ Test

[Intel-gfx] [PATCH] drm/i915/cnl: Don't trust VBT's alternate pin for port D for now.

Cannon Lake's VBT that is currently available for B0 stepping states that port D uses alternate pin 3 messing up with the default pin-port mapping table. Using that information we cannot get HDMI working properly. So for now we don't relly on VBT for this information. Cc: Clint Taylor

[Intel-gfx] [PATCH] drm/i915/cnl: Gen10 render context size.

No change on render context size is required for Gen10. So this patch doesn't change the default behaviour, but only avoid the missing_case message. Cc: Ben Widawsky Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_engine_cs.c | 1

[Intel-gfx] [PATCH] drm/i915/cnl: Enable Audio Pin Buffer.

Starting on CNL, we need to enable Audio Pin Buffer. By the spec it seems that this is part of audio programming, so let's give them the hability to set/unset this as needed. v2: With a hook so audio driver can control it. v3: Put back reg definition lost on v2. Cc: Dhinakaran Pandiyan

[Intel-gfx] [PATCH] drm/i915/cnl: Cannonlake color init.

Cannonlake has same color setup as Geminilake. Legacy color load luts doesn't work anymore on Cannonlake+. Cc: Clint Taylor Cc: Ander Conselvan de Oliveira Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 3/3] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.

Cannonlake uses a different swing voltage initalization sequence scheme that doesn't require these old functions. All other DDI, voltage swing and PLLs initialialization and configuration are already in place for Cannonlake. This patch only removes unecessary steps probably saving us from some

[Intel-gfx] [PATCH 2/3] drm/i915/cnl: Dump the right pll registers when dumping pipe config.

Different from SKL we don't need ctrl1 and cfgcr2, but we need to dump cfgcr0 amd cfgcr1 instead. v2: rebase and commit message Cc: Clint Taylor Cc: Mika Kahola Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 1/3] drm/i915/cnl: Add allowed DP rates for Cannonlake.

One warning is that in order to get DPLL Link rates 3240 and 4050 that allows 648000 and 81 is that: "Some SKUs may require elevated I/O voltage to support this." v2: Rebase on top of source_rates changes. Cc: Clint Taylor Cc: Mika Kahola

[Intel-gfx] [PATCH] drm/i915/cnl: Get DDI clock based on PLLs.

PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. v2: Mika pointed out that 24 was hardcoded while it should consider ref clock that can be either 24KHz or 19.2KHz on CNL. Reviewed-by: Mika Kahola

[Intel-gfx] [PATCH] drm/i915/cnl: Add max allowed Cannonlake DC.

This is a follow-up after enabling DC states with commit: "drm/i915/DMC/CNL: Load DMC on CNL". Cc: Anusha Srivatsa Cc: Imre Deak Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- 1 file

[Intel-gfx] [PATCH] drm/i915/cnl: Inherit RPS stuff from previous platforms.

Apparently no change on RPS stuff from previous platforms. v2: Merging to rps related patches in one and also adding missed cases. Cc: David Weinehall Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 20

[Intel-gfx] [PATCH 20/22] drm/i915: Refactor __intel_atomic_commit_tail()

From: Ville Syrjälä Split intel_atomic_commit_tail() into a lower level function that does the actual commit, and a higher level one that waits for the dependencies and signals the commit as done. We'll reuse the lower level function to perform commits during GPU

[Intel-gfx] [PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

From: Ville Syrjälä For i915 GPU reset handling we'll want to be able to duplicate the state that was last commited to the hardware. For that purpose let's start to track the commited state for each object and provide a way to duplicate the commmited state into a

[Intel-gfx] [PATCH 17/22] drm/atomic: Fix up the kernel docs for the state duplication functions

From: Ville Syrjälä Coccinelle doesn't fix up the docs for us, so let's do it manually. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 12 +--- include/drm/drm_connector.h | 2 +-

[Intel-gfx] [PATCH 19/22] drm/i915% Store vma gtt offset in plane state

From: Ville Syrjälä To avoid having to deference plane_state->vma during the commit phase of plane updates, let's store the vma gtt offset (or the bus address when we need it) in the plane state. This is crucial for doing the modeset operations during GPU reset as

[Intel-gfx] [PATCH v5 22/22] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore

From: Ville Syrjälä Introduce an rw_semaphore to protect the display commits. All normal commits use down_read() and hence can proceed in parallel, but GPU reset will use down_write() making sure no other commits are in progress when we have to pull the plug on the

[Intel-gfx] [PATCH 18/22] drm: Return the connector from drm_connector_get()

From: Ville Syrjälä Make drm_connector_get() return the connector. This allows the nice pattern of 'foo->connector = drm_connector_get(connector)' Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 3 +--

[Intel-gfx] [PATCH 14/22] drm/arm: s/old_state/old_mali_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mali_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/malidp_crtc.c | 10 +- 1 file changed, 5

[Intel-gfx] [PATCH 12/22] drm/atomic: Make private objs proper objects

From: Ville Syrjälä Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector

[Intel-gfx] [PATCH 15/22] drm/mediatek: s/old_state/old_mtk_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mtk_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 4 ++-- 1 file changed, 2

[Intel-gfx] [PATCH 16/22] drm/atomic: Pass old state explicitly to .atomic_duplicate_state()

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. I wanted to make the old_state const, but that would have results in tons of new warnings because some

[Intel-gfx] [PATCH 11/22] drm/atomic: Convert private_objs to drm_dynarray

From: Ville Syrjälä state->private_objs grows dynamically, so switch it over to use the new drm_dynarray helper. Cc: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c

[Intel-gfx] [PATCH 13/22] drm/atomic: Pass old state to __drm_atomic_helper_crtc_duplicate_state() & co. explicitly

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. @r@ identifier F =~ "^__drm_atomic_helper_.*_duplicate_state$"; identifier O, S; type T, TS; @@ F(T O, TS *S

[Intel-gfx] [PATCH 09/22] drm/atomic: Convert state->connectors to drm_dynarray

From: Ville Syrjälä state->connectors[] can grows dynamically, so we can switch over to using the new drm_dynarray. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 49 +++--

[Intel-gfx] [PATCH 10/22] drm/atomic: Remove pointless private object NULL state check

From: Ville Syrjälä We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan Reviewed-by: Daniel Vetter Signed-off-by: Ville

[Intel-gfx] [PATCH 07/22] drm/i915: Eliminate crtc->state usage from intel_atomic_commit_tail and .crtc_update()

From: Ville Syrjälä We already have the correct new crtc state so just use that instead of crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[Intel-gfx] [PATCH 06/22] drm/i915: Eliminate crtc->state usage from intel_update_pipe_config()

From: Ville Syrjälä Pass the correct new crtc state to intel_update_pipe_config() instead of using crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 9

[Intel-gfx] [PATCH 08/22] drm: Add drm_dynarray

From: Ville Syrjälä Add a small helper that gives us dynamically growing arrays. We have a couple hand rolled implementations of this in the atomic code, which we can unify to use a common implementation. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 05/22] drm/i915: Eliminate obj->state usage from pre/post plane update

From: Ville Syrjälä Dig up the appropriate new crtc and plane states from the top level atomic state in intel_pre_plane_update() and intel_post_plane_update(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 01/22] drm/i915: Pass the new crtc state to color management code

From: Ville Syrjälä In an effort to eliminate the obj->state usage let's pass on the new crtc state pointer (which we already have!) to the color management code. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 03/22] drm/i915: Eliminate obj->state usage in g4x/vlv/chv wm computation

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/intel_drv.h | 8 drivers/gpu/drm/i915/intel_pm.c | 30 +++--- 3 files

[Intel-gfx] [PATCH 04/22] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

From: Ville Syrjälä Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself

[Intel-gfx] [PATCH 02/22] drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()

From: Ville Syrjälä Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 18

[Intel-gfx] [PATCH v2 00/22] drm/i915: Fix pre-g4x GPU reset, again (v2)

From: Ville Syrjälä OK, so here's the full version of my rw_semaphore GPU vs. display reset fix. The only issue I'm aware of is that SKL watermark code still uses obj->state and thus I have no clue what would happen if one tries to run this on SKL. Untangling that

[Intel-gfx] [maintainer-tools RFC PATCH] drm-intel: Link to .html instead of .rst

Ideally .rst would referrence .rst with :ref:`` but since these documentation are different repository we cannot link like this. However I believe the main usage is through the compiled html pages and since we already reference another .html here I believe we should use our daily compiled doc.

[Intel-gfx] [maintainer-tools PATCH] drm-intel: Fix links to torvalds documentation.

All process related docs has moved to the new "process" folder, but also all .txt migrated to .rst as well. Signed-off-by: Rodrigo Vivi --- drm-intel.rst | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drm-intel.rst b/drm-intel.rst

Re: [Intel-gfx] [PATCH] drm/i915: Disable per-engine reset for Broxton

Quoting Michel Thierry (2017-07-06 18:02:13) > On Thu, Jul 6, 2017 at 12:11 AM, Chris Wilson > wrote: > > Quoting Michel Thierry (2017-07-06 02:24:26) > >> On 04/07/17 09:09, Chris Wilson wrote: > >> > Triggering a GPU reset for one engine affects another, notably >

[Intel-gfx] [PATCH v2 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

Quoting Ville: "the forcewake timer might still be active until the uncore suspend, and having active forcewakes while we've already told the GT wake stuff to stop acting normally doesn't seem quite right to me." Reported-by: Ville Syrjälä Suggested-by: Imre Deak

[Intel-gfx] [PATCH v2 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier

[Intel-gfx] [PATCH v2 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which

[Intel-gfx] [PATCH v2 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(_priv->pm.wakeref_count);

Re: [Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

On 7/6/2017 10:59 AM, Chris Wilson wrote: > If there are no conflicts, then just skip the patch, and really there > shouldn't be since the writes we care about are ordered and the writes > we don't, we don't. We will need to move to per-context hwsp in the near > future which should alleviate

Re: [Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

Quoting Daniele Ceraolo Spurio (2017-07-06 17:10:40) > On gen8+ we're currently using the PPHWSP of the kernel ctx as the > global HWSP. However, when the kernel ctx gets submitted (e.g. from > __intel_autoenable_gt_powersave) the HW will use that page as both > HWSP and PPHWSP. Currently we're

Re: [Intel-gfx] [PATCH i-g-t 3/3] tests/gem_reset_stats: Enforce full chip reset mode before run

On 06/07/17 04:12, Arkadiusz Hiler wrote: On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote: Platforms with per-engine reset enabled (i915.reset=2) are unlikely to perform a full chip reset, keeping the reset_count unmodified. In order to keep the expectations of this test, enforce

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise independence of per-engine resets

On 05/07/17 04:48, Chris Wilson wrote: If all goes well, resetting one engine should not affect the operation of any others. So to test this, we setup a continuous stream of requests onto to each of the "innocent" engines whilst constantly resetting our target engine. Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915: Disable per-engine reset for Broxton

On Thu, Jul 6, 2017 at 12:11 AM, Chris Wilson wrote: Quoting Michel Thierry (2017-07-06 02:24:26) On 04/07/17 09:09, Chris Wilson wrote: > Triggering a GPU reset for one engine affects another, notably > corrupting the context status buffer (CSB) effectively losing

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lrc: allocate separate page for HWSP

== Series Details == Series: drm/i915/lrc: allocate separate page for HWSP URL : https://patchwork.freedesktop.org/series/26927/ State : success == Summary == Series 26927v1 drm/i915/lrc: allocate separate page for HWSP https://patchwork.freedesktop.org/api/1.0/series/26927/revisions/1/mbox/

[Intel-gfx] [PATCH i-g-t 0/7] igt: Add support for testing writeback connectors

We're trying to introduce support for writeback connectors, a way to expose in DRM the hardware functionality from display engines that allows to write back into memory the result of the DE's composition of supported planes. Generic DRM support is available here [1] and will be merged once this

[Intel-gfx] [PATCH i-g-t 5/7] kms_writeback: Add writeback-check-output

From: Brian Starkey Add a test which makes commits using the writeback connector, and checks the output buffer hash to make sure it is/isn't written as appropriate. Signed-off-by: Brian Starkey Signed-off-by: Liviu Dudau ---

[Intel-gfx] [PATCH i-g-t 2/7] lib/igt_kms: Add writeback support in lib/

From: Brian Starkey Add support in igt_kms for Writeback connectors, with the ability to attach framebuffers and retrieve fences. Signed-off-by: Brian Starkey Signed-off-by: Liviu Dudau --- lib/igt_aux.c | 1 +

[Intel-gfx] [PATCH i-g-t 3/7] kms_writeback: Add initial writeback tests

From: Brian Starkey Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and WRITEBACK_FB_ID properties on writeback connectors, ensuring their behaviour is correct. Signed-off-by: Brian Starkey Signed-off-by: Liviu Dudau

[Intel-gfx] [PATCH i-g-t 7/7] kms_writeback: Add tests using a cloned output

From: Brian Starkey Update the connector search to also optionally attempt to find a non-writeback connector to clone to. Add a subtest which is the same as writeback-check-output, but also clones to the second connector. Signed-off-by: Brian Starkey

  1   2   >