[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev locking + deferred setup take 3 (rev2)

== Series Details == Series: fbdev locking + deferred setup take 3 (rev2) URL : https://patchwork.freedesktop.org/series/26819/ State : success == Summary == Series 26819v2 fbdev locking + deferred setup take 3 https://patchwork.freedesktop.org/api/1.0/series/26819/revisions/2/mbox/ Test

[Intel-gfx] [PATCH] drm/fb-helper: Stop using mode_config.mutex for internals

Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

Regards Shashank On 7/4/2017 9:26 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: 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

Re: [Intel-gfx] [PATCH v5 02/17] drm: add YCBCR 420 capability identifier

Regards Shashank On 7/4/2017 9:25 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote: 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

[Intel-gfx] [PATCH v3 11/16] drm: i915: remove dead code and pointless local lut storage

The driver stores lut values from the fbdev interface, and is able to give them back, but does not appear to do anything with these lut values. The generic fb helpers have replaced this function, and may even have made the driver work for the C8 mode from the fbdev interface. But that is untested.

Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support

On Tue, Jul 4, 2017 at 5:28 PM, Takashi Iwai wrote: > On Tue, 04 Jul 2017 17:14:39 +0200, > Daniel Vetter wrote: >> On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter wrote: >> >> Now I took a closer look, and this appears rather like a brown paper >> >> bag bug, not

[Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than

[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev locking + deferred setup take 3

== Series Details == Series: fbdev locking + deferred setup take 3 URL : https://patchwork.freedesktop.org/series/26819/ State : success == Summary == Series 26819v1 fbdev locking + deferred setup take 3 https://patchwork.freedesktop.org/api/1.0/series/26819/revisions/1/mbox/ Test

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Add option to support dynamic backlight via DPCD"

== Series Details == Series: Revert "drm/i915: Add option to support dynamic backlight via DPCD" URL : https://patchwork.freedesktop.org/series/26818/ State : success == Summary == Series 26818v1 Revert "drm/i915: Add option to support dynamic backlight via DPCD"

Re: [Intel-gfx] [PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals

On Tue, Jul 4, 2017 at 5:40 PM, Ville Syrjälä wrote: >> + mutex_lock(_helper->dev->mode_config.mutex); >> drm_enable_connectors(fb_helper, enabled); >> + if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0) > > This changes the order

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

Triggering a GPU reset for one engine affects another, notably corrupting the context status buffer (CSB) effectively losing track of inflight requests. Adding a few printks: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ad41836fa5e5..a969456bc0fa 100644 ---

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH v5 02/17] drm: add YCBCR 420 capability identifier

On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals

On Tue, Jul 04, 2017 at 05:18:28PM +0200, Daniel Vetter wrote: > Those are now all protected using fb_helper->lock. > > v2: We still need to hold mode_config.mutex right around calling > connector->fill_modes. > > v3: I forgot to hold mode_config.mutex while looking at > connector->status and

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 10/13] drm/fb-helper: Support deferred setup

On Tue, Jul 04, 2017 at 05:18:30PM +0200, Daniel Vetter wrote: > FB helper code falls back to a 1024x768 mode if no outputs are connected > or don't report back any modes upon initialization. This can be annoying > because outputs that are added to FB helper later on can't be used with > FB helper

Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support

On Tue, 04 Jul 2017 17:14:39 +0200, Daniel Vetter wrote: > > On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter wrote: > >> Now I took a closer look, and this appears rather like a brown paper > >> bag bug, not about the deferred probe or module dependency. > >> The fix patch is

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 05:09:36PM +0200, Andrzej Hajda wrote: > On 04.07.2017 16:25, Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: > >> On 04.07.2017 14:44, Ville Syrjälä wrote: > >>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: >

[Intel-gfx] [PATCH 13/13] drm/hisilicon: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Dont' resurrect drm_vblank_cleanup. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong

[Intel-gfx] [PATCH 11/13] drm/i915: Protect against deferred fbdev setup

We could probably hit this already with our current async fbdev init, but it's much easier to hit this with the new deferred fbdev setup that I'm working on polishing. Cc: Maarten Lankhorst Reported-by: Maarten Lankhorst

[Intel-gfx] [PATCH 12/13] drm/exynos: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already. Cc: Inki Dae Cc: Joonyoung Shim

[Intel-gfx] [PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals

Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to

[Intel-gfx] [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths

Like with panning and modesetting, and like with those, stick with simple drm_modeset_locking_all for the legacy path, and the full atomic dance for atomic drivers. This means a bit more boilerplate since setting up the atomic state machinery is rather verbose, but then this is shared code for

Re: [Intel-gfx] [PATCH 13/13] drm/atomic-helper: Realign function parameters

On Tue, Jun 27, 2017 at 11:42:53AM -0400, Harry Wentland wrote: > On 2017-06-27 10:59 AM, Daniel Vetter wrote: > > Too jarring. > > > > Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic > > helpers (v2)") > > Cc: Andrey Grodzovsky > > Cc: Alex

[Intel-gfx] [PATCH 10/13] drm/fb-helper: Support deferred setup

FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place

[Intel-gfx] [PATCH 07/13] drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Same game as with the panning function, use drm_modeset_lock_all for legacy paths, and a proper acquire ctx w/w mutex dance for atomic. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 06/13] drm/fb-helper: Push locking into pan_display_atomic|legacy

For the legacy path we'll keep drm_modeset_lock_all, for the atomic one we drop the use of the magic implicit context and wire it up properly. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 03/13] drm/fb-helper: Add top-level lock

From: Thierry Reding Introduce a new top-level lock for the FB helper code. This will allow better locking granularity and avoid the need to abuse modeset locking for this purpose instead. This patch just adds the new lock everywhere we currently grab mode_config->mutex

[Intel-gfx] [PATCH 01/13] drm/fb-helper: Push down modeset lock into FB helpers

From: Thierry Reding Move the modeset locking from drivers into FB helpers. v2: Also handle intel_connector_add_to_fbdev. v3: Prevent race in intel_dp_mst with ->detect (Maarten) Cc: Maarten Lankhorst Cc: Alex Deucher

[Intel-gfx] [PATCH 04/13] drm/fb-helper: Push locking in fb_is_bound

That function only needs to take the individual crtc locks, not all the kms locks. Push down the locking and then minimize it. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 00/13] fbdev locking + deferred setup take 3

Hi all, Here's the locking patches respun with Maarten's review. I think that part is ready for merging. The deferred setup itself needs more thought, since both Maarten and Liviu are still unhappy with what happens between the deferred setup and fbcon. Cheers, Daniel Daniel Vetter (9):

[Intel-gfx] [PATCH 02/13] drm/i915: Drop FBDEV #ifdev in mst code

Since commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae Author: Archit Taneja Date: Wed Aug 5 12:28:57 2015 +0530 drm: Add top level Kconfig option for DRM fbdev emulation this is properly handled using dummy functions. This essentially undoes commit

[Intel-gfx] [PATCH 05/13] drm/fb-helper: Drop locking from the vsync wait ioctl code

Like with the drm-native vblank wait ioctl we can entirely rely on the spinlocks in drm_vblank.c, no need at all to take expensive mutexes. The only reason we had to take mode_config.mutex was to protect the fbdev helper's data-structures, but that's now done by fb_helper->lock. Cc: John Stultz

Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support

On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter wrote: >> Now I took a closer look, and this appears rather like a brown paper >> bag bug, not about the deferred probe or module dependency. >> The fix patch is below. Could you check whether it works? > > Yay, this works! > >

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 04.07.2017 16:25, Ville Syrjälä wrote: > On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: >> On 04.07.2017 14:44, Ville Syrjälä wrote: >>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > From:

[Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"

This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. The introduction of dynamic backlight control causes Lenovo ThinkPad X1 Carbon 4th Gen to boot to a black screen; presumably the backlight is off. Signed-off-by: David Weinehall ---

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Consolidate get_fence with pin_fence

On 03/07/2017 11:14, Chris Wilson wrote: Following the pattern now used for obj->mm.pages, use just pin_fence and unpin_fence to control access to the fence registers. I.e. instead of calling get_fence(); pin_fence(), we now just need to call pin_fence(). This will make it easier to reduce the

[Intel-gfx] [PATCH i-g-t v2] tests/gem_mocs_settings: Fix LNCFCMOCS testing and extract the subtests

Testing LNCFCMOCS values on non-render engines is tricky. The values in those registers are lost on RC6, which means that if users of non-render engines want to see the proper values, they need to obtain a forcewake and execute something on render (relying on it to restore the values) before using

Re: [Intel-gfx] [PATCH v4] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

On Fri, Jun 30, 2017 at 09:33:48AM -0700, Manasi Navare wrote: > This patch fixes the DP AUX CH timeouts observed during CI IGT > tests thus fixing the CI failures. This is done by adding a > quirk for a particular PCI device that requires the panel power > cycle delay (T12) to be set to 800ms

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode

On Mon, Jul 03, 2017 at 09:28:00PM +0530, Mahesh Kumar wrote: > Hi, > > > On Monday 03 July 2017 07:32 PM, Ville Syrjälä wrote: > > On Sat, Jul 01, 2017 at 09:35:12AM +0530, Mahesh Kumar wrote: > >> Hi, > >> > >> > >> On Friday 30 June 2017 05:56 PM, Ville Syrjälä wrote: > >>> On Fri, Jun 30,

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI YCBCR output handling in DRM layer

== Series Details == Series: HDMI YCBCR output handling in DRM layer URL : https://patchwork.freedesktop.org/series/26814/ State : success == Summary == Series 26814v1 HDMI YCBCR output handling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/26814/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: > On 04.07.2017 14:44, Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > >> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > >>> From: Ville Syrjälä >

[Intel-gfx] [PATCH v5 13/17] 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 v5 14/17] 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 v5 12/17] 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 v5 17/17] 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 V4: Added r-b from

[Intel-gfx] [PATCH v5 07/17] 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 v5 16/17] 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 V5: Added r-b from Ander Cc: Ville Syrjala Cc: Ander

[Intel-gfx] [PATCH v5 15/17] 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 v5 09/17] 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 v5 06/17] drm/edid: rename macro for CEA extended-tag

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 v5 11/17] 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 v5 05/17] 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 v5 10/17] 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 v5 08/17] 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 v5 04/17] 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. V5: Introduced the patch in series. Cc: Ville Syrjala

[Intel-gfx] [PATCH v5 03/17] 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 v5 01/17] 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 v5 00/17] 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,

[Intel-gfx] [PATCH v5 02/17] 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

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 04.07.2017 14:44, Ville Syrjälä wrote: > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: >> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch

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

When a CRC comparison error occurs, it is quite useful to get a dump of both the frame obtained from the chamelium and the reference in order to compare them. This implements the frame dump, with a configurable path that enables the use of this feature. Signed-off-by: Paul Kocialkowski

[Intel-gfx] [PATCH i-g-t v2 2/4] tests/ chamelium: Remove the frame dump tests

The frame dump tests provide no additional functionality over CRC tests and are considerably slower. Thus, these tests should be considered as poorer duplicates and removed. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 53

[Intel-gfx] [PATCH i-g-t v2 3/4] lib/igt_chamelium: Add support for dumping chamelium frames to a png

This introduces a chamelium_write_frame_to_png function that saves a Chamelium frame dump to a png file. This should be useful when a frame comparison with a reference fails. --- lib/igt_chamelium.c | 32 lib/igt_chamelium.h | 3 +++ 2 files changed, 35

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

This introduces CRC calculation for reference frames, instead of using hardcoded values for them. The rendering of reference frames may differ from machine to machine, especially due to font rendering, and the frame itself may change with subsequent IGT changes. These differences would cause the

[Intel-gfx] [PATCH i-g-t v4 2/3] chamelium: Remove init reset duplicate in favor of per-test reset

Since most tests are already doing a reset, there is no need to duplicate it at init time. This removes that duplicate reset and adds a call to reset_state where in-test resets where not done previously. Signed-off-by: Paul Kocialkowski --- lib/igt_chamelium.c

[Intel-gfx] [PATCH i-g-t v4 1/3] tests/chamelium: Update connector state without reprobe when possible

This renames the reprobe_connector function to update_connector and ensures that full reprobe of the connector is only done when really necessary (e.g. when changing the EDID). A full reprobe takes time and is not required for updating the connector state. Thus, this allows executing tests

[Intel-gfx] [PATCH i-g-t v4 3/3] Make igtrc configuration common, with configurable suspend/resume delay

This adds support for configurable suspend/resume delay and takes the occasion to move igtrc configuation from igt_chamelium to igt_core. This way, suspend/resume delay configuration can be used for all tests. Signed-off-by: Paul Kocialkowski ---

Re: [Intel-gfx] [PATCH i-g-t] igt/debugfs_test: Skip dummy reads for crtc-n/crc/data

On Mon, Jul 03, 2017 at 01:19:33PM +0300, Abdiel Janulgue wrote: > When descending thru debugfs directory. Doing this tends to > takes forever. CRC pipe read tests for this are already > covered under kms_pipe_crc_basic. > > v2: Be more verbose that the check is meant for the crtc control data >

[Intel-gfx] [PATCH i-g-t] configure.ac: Make AMDGPU depend on libdrm >= 2.4.76

AMDGPU_FAMILY_AI was introduced in commit being part of libdrm 2.4.76 release and amd_basic tests are using that define. Since the module is turned on by default this results in compilation failing on machines with older libdrm. Let make them fail on ./configure step instead. Cc: Leo Liu

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Report execlists irq bit in debugfs

== Series Details == Series: series starting with [01/10] drm/i915: Report execlists irq bit in debugfs URL : https://patchwork.freedesktop.org/series/26806/ State : success == Summary == Series 26806v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > > 3D to 2D mode in a timely fashion if

Re: [Intel-gfx] [PATCH] drm/i915: Unpin vma iomapping when fbdev is destroyed

Quoting Tvrtko Ursulin (2017-07-04 13:33:28) > > On 04/07/2017 12:29, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-07-04 12:26:31) > >> > >> On 04/07/2017 11:17, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2017-07-04 10:46:40) > From: Tvrtko Ursulin >

Re: [Intel-gfx] [PATCH] drm/i915: Unpin vma iomapping when fbdev is destroyed

On 04/07/2017 12:29, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-04 12:26:31) On 04/07/2017 11:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-04 10:46:40) From: Tvrtko Ursulin If we don't release the iomapping we are not able to unpin the vma

[Intel-gfx] [PATCH 03/10] drm/i915: Serialize per-engine resets against new requests

We rely on disabling the execlists (by stopping the tasklet) to prevent new requests from submitting to the engine ELSP before we are ready. However, we re-enable the engine before we call init_hw which gives userspace the opportunity to subit a new request which is then overwritten by init_hw --

[Intel-gfx] [PATCH 02/10] drm/i915: Reset context image on engines after triggering the reset

We try to fixup the context image after the reset to ensure that there are no more pending writes from the hw that may conflict and to fixup any that were in flight. Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery") Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 08/10] drm/i915: Wake up waiters after setting the WEDGED bit

After setting the WEDGED bit, make sure that we do wake up waiters as they may not be waiting for a request completion yet, just for its execution. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[Intel-gfx] [PATCH 01/10] drm/i915: Report execlists irq bit in debugfs

As part of the knowing whether there is outstanding data in the CSB, also check whether there is an outstanding IRQ notification. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Reviewed-by:

[Intel-gfx] [PATCH 09/10] drm/i915: Assert that machine is wedged for nop_submit_request

We should only ever do nop_submit_request when the machine is wedged, so assert it is so. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 06/10] drm/i915: Check the execlist queue for pending requests before declaring idle

Including a check against the execlist queue before calling the engine idle and passing hangcheck. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c

[Intel-gfx] [PATCH 04/10] drm/i915: Flush the execlist ports if idle

When doing a GPU reset, the CSB register will be trashed and we will lose any context-switch notifications that happened since the tasklet was disabled. If we find that all requests on this engine were completed, we want to make sure that the ELSP tracker is similarly empty so that we do not feed

[Intel-gfx] [PATCH 05/10] drm/i915: Check execlist/ring status during hangcheck

Before we declare an engine as idle, check if there are any pending execlist context-switches and if the ring itself reports as idle. Otherwise, we may be left in a situation where we miss a crucial execlist event (or something more sinister) yet the requests complete. Since the seqno write

[Intel-gfx] [PATCH 07/10] drm/i915: Clear execlist port[] before updating seqno on wedging

When we wedge the device, we clear out the in-flight requests and advance the breadcrumb to indicate they are complete. However, the breadcrumb advance includes an assert that the engine is idle, so that advancement needs to be the last step to ensure we pass our own sanity checks. Signed-off-by:

[Intel-gfx] [PATCH 10/10] drm/i915: Clear engine irq posted following a reset

When the GPU is reset, we want to discard all pending notifications as either we have manually completed them, or they are no longer applicable. Make sure we do reset the engine->irq_posted prior to re-enabling the engine (e.g. the interrupt tasklets) in i915_gem_reset_finish_engine().

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

Quoting Tvrtko Ursulin (2017-07-04 12:45:59) > > On 04/07/2017 11:06, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-07-04 10:59:29) > >> > >> On 22/06/2017 17:02, Chris Wilson wrote: > >>> Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer > >>> flushes") adds a

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > 3D to 2D mode in a timely fashion if the source simply stops sending the > HDMI infoframe. The suggested

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

On 04/07/2017 11:06, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-04 10:59:29) On 22/06/2017 17:02, Chris Wilson wrote: Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only

Re: [Intel-gfx] [PATCH] drm/i915: Unpin vma iomapping when fbdev is destroyed

Quoting Tvrtko Ursulin (2017-07-04 12:26:31) > > On 04/07/2017 11:17, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-07-04 10:46:40) > >> From: Tvrtko Ursulin > >> > >> If we don't release the iomapping we are not able to unpin the > >> vma which then gets leaked.

Re: [Intel-gfx] [PATCH] drm/i915: Unpin vma iomapping when fbdev is destroyed

On 04/07/2017 11:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-04 10:46:40) From: Tvrtko Ursulin If we don't release the iomapping we are not able to unpin the vma which then gets leaked. Oh, we still do unpin the vma on closing the object and we don't

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Pin fence for iomap

Quoting Tvrtko Ursulin (2017-07-04 12:19:17) > > On 04/07/2017 11:04, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-07-04 10:53:53) > >> > >> On 03/07/2017 11:14, Chris Wilson wrote: > >>> We probably want for the caller to specify whether the fence should be > >>> pinned for their usage,

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Pin fence for iomap

On 04/07/2017 11:04, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-04 10:53:53) On 03/07/2017 11:14, Chris Wilson wrote: We probably want for the caller to specify whether the fence should be pinned for their usage, but at the moment all callers do want the associated fence, or none,

Re: [Intel-gfx] [PATCH] drm/i915: Fix use-after-free of context during free_contexts

Quoting Matthew Auld (2017-07-01 00:42:35) > On 1 July 2017 at 00:05, Chris Wilson wrote: > > When iterating the list of contexts to free, we need to use a safe > > iterator as we are freeing the link as we go. Pass an extra thick brown > > paper bag. > > > > Fixes:

Re: [Intel-gfx] [PATCH] drm/i915: Unpin vma iomapping when fbdev is destroyed

Quoting Tvrtko Ursulin (2017-07-04 10:46:40) > From: Tvrtko Ursulin > > If we don't release the iomapping we are not able to unpin the > vma which then gets leaked. Oh, we still do unpin the vma on closing the object and we don't hold any extra object reference for the

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Mon, Jul 03, 2017 at 10:19:38PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > 3D to 2D mode in a timely fashion if the source simply stops sending the > HDMI

Re: [Intel-gfx] [PATCH 1/2] video/hdmi: Allow "empty" HDMI infoframes

On Tue, Jul 04, 2017 at 11:41:27AM +0200, Andrzej Hajda wrote: > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe > > when switching from 3D to 2D mode,

Re: [Intel-gfx] TearFree true and Screen Rotation on Skylake

Quoting Mattias Nyman (2017-07-04 10:50:00) > Hey! > I am unable to rotate my screen to left or right using Skylake Integrated > Graphics with the  > Option TearFree true > in the /usr/share/X11/xorg.conf.d/20-intel.conf > > The screen turns black for a second, before returning to its previous >

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

Quoting Tvrtko Ursulin (2017-07-04 10:59:29) > > On 22/06/2017 17:02, Chris Wilson wrote: > > Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer > > flushes") adds a dependency to ifbdev->vma when flushing the framebufer, > > but the checks are only against the existence of the

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Pin fence for iomap

Quoting Tvrtko Ursulin (2017-07-04 10:53:53) > > On 03/07/2017 11:14, Chris Wilson wrote: > > We probably want for the caller to specify whether the fence should be > > pinned for their usage, but at the moment all callers do want the > > associated fence, or none, so take it on their behalf. >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Unpin vma iomapping when fbdev is destroyed

== Series Details == Series: drm/i915: Unpin vma iomapping when fbdev is destroyed URL : https://patchwork.freedesktop.org/series/26802/ State : success == Summary == Series 26802v1 drm/i915: Unpin vma iomapping when fbdev is destroyed

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

On 22/06/2017 17:02, Chris Wilson wrote: Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a

  1   2   >