[Intel-gfx] [PATCH I-G-T 1/2] igt/kms_pipe_crc_basic: Print pipe name when skipping

Signed-off-by: Gabriel Krisman Bertazi --- tests/kms_pipe_crc_basic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index f49b434857e6..177211249808 100644 --- a/tests/kms_pipe_crc_basic.c

[Intel-gfx] [PATCH I-G-T 2/2] igt/kms_pipe_crc_basic: Skip test before system suspend

Do a dummy crc read such that if there are no valid outputs for the pipe, it skip the test before doing a system suspend. Signed-off-by: Gabriel Krisman Bertazi --- tests/kms_pipe_crc_basic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] [RFC] drm/i915/skl+: enable PF_ID interlace mode in SKL

On Mon, Jun 19, 2017 at 05:50:28PM +0530, Mahesh Kumar wrote: > Hi Ville, > > Thanks for review > > > On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote: > > On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote: > >> In previous GEN default Interlace mode enabled is IF-ID mode, but

[Intel-gfx] [PATCH] drm/i915: Wait for concurrent global resets to complete

If we enter i915_handle_error() a second time and a global reset is already in progress, we can simply wait for completion of the first reset. Currently we exit earlier prior to the actual reset being performed -- the worst of both worlds! Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for concurrent global resets to complete

== Series Details == Series: drm/i915: Wait for concurrent global resets to complete URL : https://patchwork.freedesktop.org/series/25994/ State : success == Summary == Series 25994v1 drm/i915: Wait for concurrent global resets to complete

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Setting pch_id for HSW/BDW in virtual environment

On 14/06/17 16:18, Joonas Lahtinen wrote: On ke, 2017-06-14 at 11:27 +, Patchwork wrote: == Series Details == Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment URL : https://patchwork.freedesktop.org/series/25772/ State : success Janie & Daniel, This patch could be

[Intel-gfx] [Bug Report] Weekly progress report WW24

Highlights: - 22 bugs open during the week - 20 bugs closed during the week - 359 total bugs remain open - 16 bugs labeled ReadyForDev during the week - 88 total bugs labeled ReadyForDev remain open Details: - Bugs open during the week

[Intel-gfx] [Regression report] Weekly regression report WW42

Link to FDO regression list:

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Mon, 19 Jun 2017 08:34:13 +0200 Gerd Hoffmann wrote: > Hi, > > > So perhaps this becomes: > > > > struct vfio_device_gfx_plane_info { > > __u64 start; > > __u64 drm_format_mod; > > __u32 drm_format; > > __u32 width; > > __u32 height; > > __u32

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Mon, 19 Jun 2017 08:38:32 +0200 Gerd Hoffmann wrote: > Hi, > > > My suggestion was to use vfio device fd for this ioctl and have > > dmabuf > > mgr fd as member in above query_plane structure, for region type it > > would be set to 0. > > Region type should be

[Intel-gfx] [PATCH v4 01/15] drm: add HDMI 2.0 VIC support for 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

[Intel-gfx] [PATCH v4 03/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 v4 02/15] drm: add YCBCR 420 capability identifier

This patch adds a bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR 420 outputs or not, so that a lot of work can be done/bypassed based on this information. One such

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

This patch adds set of helper functions for YCBCR HDMI output handling. These functions provide functionality like: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 mode. - get the highest subsamled ycbcr output. - get the lowest subsamled ycbcr

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

HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI output modes other than RGB, this patch adds a function in DRM layer, to add the output colorspace information in the AVI

[Intel-gfx] [PATCH v4 04/15] drm/edid: parse YCBCR 420 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 v4 07/15] drm: create hdmi output property

HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR 444 - YCBCR 422 - YCBCR 420 This patch adds a drm property "hdmi_output_format", using which, a user can specify its preference,

[Intel-gfx] [PATCH v4 06/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 v4 05/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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add information to missing case.

On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote: > On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote: > > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote: > > > > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote: > > > > > > > On Fri, 2017-06-16 at 21:21

[Intel-gfx] [PATCH v2] drm/i915: Wait for concurrent global resets to complete

If we enter i915_handle_error() a second time and a global reset is already in progress, we can simply wait for completion of the first reset. Currently we exit earlier prior to the actual reset being performed -- the worst of both worlds! v2: Plug into the existing reset_queue, and remember that

[Intel-gfx] [PATCH v4 00/15] HDMI YCBCR output handling in DRM layer

This patch series adds support for YCBCR HDMI output handling in DRM layer. The main aim of this patch series was to handle YCBCR 4:2:0 output for HDMI 2.0 displays. But while providing a framework to handle non-RGB outputs, support for YCBCR 4:4:4 and 4:2:2 was also added. First 2 patches,

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Don't try detecting sinks on ports already in use

Ville Syrjälä writes: >> mutex_lock(>mode_config.mutex); >> DRM_DEBUG_KMS("running encoder hotplug functions\n"); >> @@ -339,13 +340,18 @@ static void i915_hotplug_work_func(struct work_struct >> *work) >> if (!intel_connector->encoder) >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for concurrent global resets to complete (rev2)

== Series Details == Series: drm/i915: Wait for concurrent global resets to complete (rev2) URL : https://patchwork.freedesktop.org/series/25994/ State : success == Summary == Series 25994v2 drm/i915: Wait for concurrent global resets to complete

[Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

This patch checks encoder level support for HDMI YCBCR outputs. HDMI output mode is a connector property, this patch checks if source and sink can support the HDMI output type selected by user. And if they both can, it commits the hdmi output type into crtc state, for further staging in driver.

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

To support ycbcr HDMI output, we need a pipe CSC block to do the RGB->YCBCR conversion, as the blender output is in RGB. 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,

[Intel-gfx] [PATCH v4 12/15] drm/i915: prepare pipe for YCBCR 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 v4 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 v4 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 Signed-off-by: Shashank

[Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

Paulo noticed that we were missing few bits clear before writing values back to the register on these RMW MMIO operations. v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo). v3: Remove unnecessary braces. (Jani). Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Cc: Paulo

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote: > Problem: > While running IGT kms_atomic_transition test suite i encountered > a hang in drmHandleEvent immidietly follwoing an atomic_commit. s/immidietly/immediately/g s/follwoing/following/g > After dumping the atomic state I relized that in

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

When HDMI output is other than RGB, we have to load the corresponding colorspace of output mode. This patch fills the colorspace of AVI infoframe as per the HDMI output mode. V2: Rebase V3: Rebase V4: Rebase Cc: Ville Syrjala Cc: Ander Conselvan De Oliveira

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev4)

== Series Details == Series: HDMI YCBCR output handling in DRM layer (rev4) URL : https://patchwork.freedesktop.org/series/22684/ State : failure == Summary == Series 22684v4 HDMI YCBCR output handling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/4/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add information to missing case.

On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote: > On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote: > > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote: > > > > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote: > > > > > > > On Fri, 2017-06-16 at

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

On Mon, 2017-06-19 at 11:08 -0700, Dhinakaran Pandiyan wrote: > Maarten and Ville noticed that we are enabling backlight via DP aux very > early in the modeset_init path via the intel_dp_aux_setup_backlight() > function, since commit e7156c833903 ("drm/i915: Add Backlight Control using > DPCD for

Re: [Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote: > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake > workarounds.") > Mika pointed out that Spec tells those 2 workarounds were not needed. > > So when double checking I confirmed that and also that by Spec >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev3)

== Series Details == Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev3) URL : https://patchwork.freedesktop.org/series/25935/ State : failure == Summary == Series 25935v3 drm/i915/cnl: Fix RMW on ddi vswing sequence.

[Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake workarounds.") Mika pointed out that Spec tells those 2 workarounds were not needed. So when double checking I confirmed that and also that by Spec they only apply to SKL and BXT. v2: Instead of increase the if/else move

[Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

Maarten and Ville noticed that we are enabling backlight via DP aux very early in the modeset_init path via the intel_dp_aux_setup_backlight() function, since commit e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)"). Looks like all we need to do during

[Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

Paulo noticed that we were missing few bits clear before writing values back to the register on these RMW MMIO operations. v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo). v3: Remove unnecessary braces. (Jani). Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Cc: Paulo

Re: [Intel-gfx] [PATCH] drm/i915: Make intel_digital_port_connected() work for any port

I have tested this for PORT A and works great to give HPD live status. Thanks for the patch. Looks good to me. On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add the missing port A handling to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev4)

== Series Details == Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev4) URL : https://patchwork.freedesktop.org/series/25935/ State : success == Summary == Series 25935v4 drm/i915/cnl: Fix RMW on ddi vswing sequence.

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

On 19/06/17 05:46, Chris Wilson wrote: Quoting Michel Thierry (2017-06-15 21:18:12) @@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private *dev_priv) lockdep_assert_held(_priv->drm.struct_mutex); - for_each_engine(engine, dev_priv, id) { -

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

On Thu, 15 Jun 2017, Imre Deak wrote: > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote: >> I believe it is worth allowing RPM to work without requiring DMC, no?! > > Not if there is no good reason for not using DMC. It was decided early > on that we won't

Re: [Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote: > On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote: > > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake > > workarounds.") > > Mika pointed out that Spec tells those 2 workarounds were not needed. > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

On Mon, Jun 19, 2017 at 07:01:21PM +, Vivi, Rodrigo wrote: > On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote: > > On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote: > > > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake > > > workarounds.") > > > Mika

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote: > On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote: > > Problem: > > While running IGT kms_atomic_transition test suite i encountered > > a hang in drmHandleEvent immidietly follwoing an atomic_commit. > > s/immidietly/immediately/g >

Re: [Intel-gfx] [PATCH] drm/i915: Make intel_digital_port_connected() work for any port

On Mon, Jun 19, 2017 at 12:06:07PM -0700, Manasi Navare wrote: > I have tested this for PORT A and works great to give HPD live status. > Thanks for the patch. Looks good to me. > > On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

== Series Details == Series: drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK. URL : https://patchwork.freedesktop.org/series/26001/ State : success == Summary == Series 26001v1 drm/i915: Remove WaDisableKillLogic and

Re: [Intel-gfx] [PATCH i-g-t v3] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

On Mon, 2017-06-19 at 12:39 +0300, Paul Kocialkowski wrote: > This adds two new tests: common-hpd-after-suspend and > common-hpd-after-hibernate that are aimed at testing HPD change > during > suspend/hibernate for both DP and HDMI, at the same time. > > The interest in bringing this test up is

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

On Mon, 19 Jun 2017, Dhinakaran Pandiyan wrote: > Maarten and Ville noticed that we are enabling backlight via DP aux very > early in the modeset_init path via the intel_dp_aux_setup_backlight() > function, since commit e7156c833903 ("drm/i915: Add Backlight Control

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

Patch merged to dinq, thanks for spotting this and also for reviews and comments. On Mon, Jun 19, 2017 at 11:39 AM, Rodrigo Vivi wrote: > Paulo noticed that we were missing few bits clear > before writing values back to the register on > these RMW MMIO operations. > > v2:

[Intel-gfx] [PATCH] drm/i915/cfl: Fix Workarounds.

During the review of Coffee Lake workarounds Mika pointed out that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC should be removed from CFL and with that I should carry the rv-b. However when doing the v2 I removed another Workaround that should remain because although not mentioned

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cfl: Fix Workarounds.

== Series Details == Series: drm/i915/cfl: Fix Workarounds. URL : https://patchwork.freedesktop.org/series/26010/ State : success == Summary == Series 26010v1 drm/i915/cfl: Fix Workarounds. https://patchwork.freedesktop.org/api/1.0/series/26010/revisions/1/mbox/ Test gem_exec_flush:

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On 06/19/2017 03:24 PM, Sean Paul wrote: On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote: On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote: Problem: While running IGT kms_atomic_transition test suite i encountered a hang in drmHandleEvent immidietly follwoing an atomic_commit.

Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for concurrent global resets to complete

On 19/06/17 08:37, Chris Wilson wrote: If we enter i915_handle_error() a second time and a global reset is already in progress, we can simply wait for completion of the first reset. Currently we exit earlier prior to the actual reset being performed -- the worst of both worlds! v2: Plug into

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hi, > My suggestion was to use vfio device fd for this ioctl and have > dmabuf > mgr fd as member in above query_plane structure, for region type it > would be set to 0. Region type should be DRM_PLANE_TYPE_PRIMARY > Can't mmap that page to get surface information. There is no way to >

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hi, > So perhaps this becomes: > > struct vfio_device_gfx_plane_info { > __u64 start; > __u64 drm_format_mod; > __u32 drm_format; > __u32 width; > __u32 height; > __u32 stride; > __u32 size; > __u32 x_pos; > __u32 y_pos; > }; Looks good.

[Intel-gfx] Updated drm-intel-testing

Hi all, Final pile of features for 4.13 New uabi: - batch bo in first slot, for faster execbuf assembly in userspace (Chris Wilson) - (sub)slice getparam, needed for mesa perf support (Robert Bragg) First pile of patches for cnl/cfl support, maintained by Rodrigo but with lots of

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

On Fri, 16 Jun 2017, Rodrigo Vivi wrote: > Paulo noticed that we were missing few bits clear > before writing values back to the register on > these RMW MMIO operations. > > v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo). > > Fixes: cf54ca8bc567 ("drm/i915/cnl:

[Intel-gfx] [PATCH i-g-t v3] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

This adds two new tests: common-hpd-after-suspend and common-hpd-after-hibernate that are aimed at testing HPD change during suspend/hibernate for both DP and HDMI, at the same time. The interest in bringing this test up is to reduce the time spent in testing, with the downside of less precision

Re: [Intel-gfx] [PATCH 5/7] drm/i915: add _PICK macro for the "a + index * (b - a)" macros

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Jani Nikula > Sent: Friday, June 16, 2017 1:56 AM > To: Zanoni, Paulo R ; intel- > g...@lists.freedesktop.org > Cc: Zanoni, Paulo R >

Re: [Intel-gfx] [PATCH] drm/i915: Differentiate between sw write location into ring and last hw read

On Thu, 15 Jun 2017, Chris Wilson wrote: > We need to keep track of the last location we ask the hw to read up to > (RING_TAIL) separately from our last write location into the ring, so > that in the event of a GPU reset we do not tell the HW to proceed into > a

Re: [Intel-gfx] Fixes that failed to backport to v4.12-rc1

On Mon, 15 May 2017, Jani Nikula wrote: > Continuing [1] for v4.12-rc1 > > The following commits have been marked as Cc: stable or fixing something > in v4.12-rc1 or earlier, but failed to cherry-pick to > drm-intel-fixes. Please see if they are worth backporting, and

Re: [Intel-gfx] [PATCH i-g-t v2] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

Hi, On Fri, 2017-06-16 at 19:28 -0400, Lyude Paul wrote: > On Fri, 2017-06-16 at 17:17 +0300, Paul Kocialkowski wrote: > > This adds two new tests: common-hpd-after-suspend and > > common-hpd-after-hibernate that are aimed at testing HPD change during > > suspend/hibernate for both DP and HDMI,

Re: [Intel-gfx] [PATCH] drm/i915: Actually attach the tv_format property to the SDVO connector

Op 15-06-17 om 19:23 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Attach the tv_format property to the SDVO connector instead of passing > a '0' in place of the pointer to the property. This got broken when > the SDVO connector properties were

[Intel-gfx] [PATCH v2 2/2] drm/i915: Do not re-calculate num_rings locally

From: Tvrtko Ursulin Since bb8f0f5abdd7 ("drm/i915: Split intel_engine allocation and initialisation") intel_info->num_rings is set early in the load sequence and so available to be used direclty in the 2nd load phase. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2) URL : https://patchwork.freedesktop.org/series/25907/ State : success == Summary == Series 25907v2 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC

On Fri, Jun 16, 2017 at 04:43:41PM -0700, Rodrigo Vivi wrote: > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake > workarounds.") > Mika pointed out that Spec tells those 2 workarounds were not needed. > > So when double checking I confirmed that and also that by Spec they

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

On 16/06/2017 17:02, Chris Wilson wrote: When userspace is doing most of the work, avoiding relocs (using NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we still spend a lot of time processing the arrays in execbuf, even though we now should have nothing to do most of the

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rmfb: Fix cursor fb size

Tested OK, also NOTE that this fixes bug 97975 /Marta > -Original Message- > From: ville.syrj...@linux.intel.com [mailto:ville.syrj...@linux.intel.com] > Sent: Monday, June 19, 2017 3:29 PM > To: intel-gfx@lists.freedesktop.org > Cc: Lofstedt, Marta > Subject:

Re: [Intel-gfx] [PATCH] [RFC] drm/i915/skl+: enable PF_ID interlace mode in SKL

Hi Ville, Thanks for review On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote: On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote: In previous GEN default Interlace mode enabled is IF-ID mode, but IF-ID mode has many limitations in SKL. This mode doesn't support y-tiling, 90-270

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

Quoting Tvrtko Ursulin (2017-06-19 13:06:18) > > On 16/06/2017 17:02, Chris Wilson wrote: > > @@ -520,7 +511,8 @@ static inline int use_cpu_reloc(const struct > > reloc_cache *cache, > > static int eb_reserve_vma(const struct i915_execbuffer *eb, > > struct i915_vma

[Intel-gfx] [PATCH i-g-t] tests/kms_rmfb: Fix cursor fb size

From: Ville Syrjälä Don't use the display mode size to determine the cursor fb size. That will lead to a framebuffer with a stride that the cursor plane won't support. Just use the max cursor size as the fb size instead. This started to trip up after i915 started

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

Quoting Michel Thierry (2017-06-15 21:18:12) > int i915_gem_reset_prepare(struct drm_i915_private *dev_priv) > { > struct intel_engine_cs *engine; > + struct drm_i915_gem_request *request; > enum intel_engine_id id; > int err = 0; > > - /* Ensure irq handler

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

Quoting Michel Thierry (2017-06-15 21:18:12) > @@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private > *dev_priv) > > lockdep_assert_held(_priv->drm.struct_mutex); > > - for_each_engine(engine, dev_priv, id) { > - tasklet_enable(>irq_tasklet); >