Re: [Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty

On Wed, 14 Jun 2017, Eric Blau wrote: > Can the following patch please be included in the next stable release? > It looks like it was submitted previously by Daniel Vetter, but has not > been included in 4.11.y yet. Thanks. The previous submission would be [1]. Please reference

Re: [Intel-gfx] [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

Hello Thierry, Thanks for the comments. In fact, that was the plan earlier, but the problem is, this function is being called from several drivers, and not all of them have the drm_connector readily available with their caller function. For few drivers, I might have to go up two to three

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

Hi Ander, On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote: On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote: On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper wrote: On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote: This reverts

Re: [Intel-gfx] [PATCH] drm/i915: fix the issue DP-1 not working in guest

To be clear, I believe right now, GVT-g architecture on upstream still only have one Virtualized DP monitor which will be on port B/D, but we have patches (not yet upstream) that have 3 virtualized DP monitors which will be attached to Port A/B/D. So we need to add this flexibility in the code

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update

== Series Details == Series: drm: add asynchrounous plane update URL : https://patchwork.freedesktop.org/series/25814/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

[Intel-gfx] [PATCH v2 6/6] drm/vc4: update cursors asynchronously through atomic

From: Gustavo Padovan Add support for async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what vc4_update_plane() did but through atomic. v4: add drm_atomic_helper_async() commit (Eric Anholt) v3: move size

[Intel-gfx] [PATCH v2 5/6] drm/msm: remove mdp5_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now. Cc: Rob Clark Cc: Archit Taneja Signed-off-by: Gustavo Padovan

[Intel-gfx] [PATCH v2 4/6] drm/msm: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what mdp5_update_cursor_plane_legacy() did but through atomic. v4: add missing atomic async commit call to

[Intel-gfx] [PATCH v2 0/6] drm: add asynchrounous plane update

From: Gustavo Padovan Hi, Another iteration on this patchset. Added some a-b and r-b tags to it and fixed issues in patch 6 reported by Eric. That patch still needs testing but the rest is tested and working, looking to be already in a good shape. More info in the

[Intel-gfx] [PATCH v2 2/6] drm/i915: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what intel_legacy_cursor_update() did but through atomic. v3: - set correct vma to new state for cleanup

[Intel-gfx] [PATCH v2 1/6] drm/atomic: initial support for asynchronous plane update

From: Gustavo Padovan In some cases, like cursor updates, it is interesting to update the plane in an asynchronous fashion to avoid big delays. The current queued update could be still waiting for a fence to signal and thus block any subsequent update until its

[Intel-gfx] [PATCH v2 3/6] drm/i915: remove intel_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits intel_cursor_plane_funcs just duplicates intel_plane_funcs now. Cc: Daniel Vetter Signed-off-by: Gustavo Padovan ---

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

> On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote: > > In a IGD passthrough environment, the real ISA bridge may doesn't exist. > > then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is > > used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Set value of fake mst encoder's hpd pin

== Series Details == Series: drm/i915: Set value of fake mst encoder's hpd pin URL : https://patchwork.freedesktop.org/series/25810/ State : success == Summary == Series 25810v1 drm/i915: Set value of fake mst encoder's hpd pin

[Intel-gfx] [PATCH] drm/i915: Set value of fake mst encoder's hpd pin

We receive hotplug event, but do not handle it. Set value of fake mst encoder's hpd pin to handle hotplug event. Before applying the patch: [ 36.595058] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x0020, dig 0x10101012, pins 0x0020 [ 36.595172]

Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

Friendly ping. Is this patch set good to go now? On Mon, Jun 5, 2017 at 2:56 PM, Puthikorn Voravootivat wrote: > This patch set contain 3 patches which are already reviewed by DK. > Another 6 patches in previous version was already merged in v7 and v9. > - First patch sets

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Set output pipe after mode change to refresh output

On Wed, 2017-06-14 at 14:47 +0300, Paul Kocialkowski wrote: > This adds a call to igt_output_set_pipe in orde to refresh output via > igt_output_refresh and ensure that mode override can take effect. > > Without this change, using a lower resolution during frame dumps > series with mode changes

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

On Wed, Jun 14, 2017 at 02:47:06PM +0300, Ander Conselvan De Oliveira wrote: > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote: > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper > > wrote: > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote: > > > >

Re: [Intel-gfx] [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

On Wed, Jun 14, 2017 at 11:17:32PM +0530, Shashank Sharma wrote: [...] > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 2e55599..d312fe1 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -4334,12 +4334,14 @@

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

I tested this on actual system and it is working fine. On Tue, Jun 13, 2017 at 1:03 PM, Dhinakaran Pandiyan < dhinakaran.pandi...@intel.com> 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() >

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

On Wed, Jun 14, 2017 at 01:02:27PM -0700, Rodrigo Vivi wrote: > On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak wrote: > > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote: > >> intel_csr_load_program can fail (if not supported by SoC, or if file > >> is size 0)

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

"dmc_payload is checked right before..." You are correct, there is no bug. It was my misunderstanding. "What if someone doesn't really want to use DMC but still wants D3hot?" or other great stuff that RPM can do without DMC firmware support? From:

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

On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak wrote: > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote: >> intel_csr_load_program can fail (if not supported by SoC, or if file >> is size 0) > > Those are really just sanity checks, they can't happen normally.

[Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX

From: Jeff McGee This completes the change started by: commit 39cccab83b7c515a2b57abe679a8cb304c8933ef Author: Chris Wilson Date: Fri May 19 09:41:40 2017 +0100 igt/pm_rps: Allow CUR to be greater than MAX (overclocking) Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

On Wed, Jun 14, 2017 at 08:11:18PM +0200, Maarten Lankhorst wrote: > Op 14-06-17 om 16:52 schreef Ville Syrjälä: > > On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: > >> Moving the wait to a helper allows callers outside of the core to > >> wait for pending updates to complete.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Misc improvements around module params (rev3)

== Series Details == Series: drm/i915: Misc improvements around module params (rev3) URL : https://patchwork.freedesktop.org/series/25482/ State : success == Summary == Series 25482v3 drm/i915: Misc improvements around module params

[Intel-gfx] [PATCH v3 2/4] drm/i915: Extend PARAMS_FOR_EACH macro with more data

Currently our PARAMS_FOR_EACH macro contains only param type and name. We use this macro to define struct members, but later on we initialize this struct using handcrafted code, which leads in some cases to use mismatched value vs. type. Let's extend our root macro with param default value to keep

[Intel-gfx] [PATCH v3 0/4] drm/i915: Misc improvements around module params

Earlier RFC proposed to extend param macros with default values. This series goes step further. v2: rename modparam instead of i915_params field v3: refactor master macro and debugfs/error printers Michal Wajdeczko (4): drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc drm/i915: Extend

[Intel-gfx] [PATCH v3 4/4] drm/i915/debugfs: Highlight modified i915 params

We know default values for all params and we know which params are safe to change. Mark params that were changed when dumping them in debugfs. v2: simplify is_default calculation for strings (Chris) v3: rebased and switched into custom seq_print macros (Michal) Suggested-by: Chris Wilson

[Intel-gfx] [PATCH v3 1/4] drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc

This modparam affects not only LVDS but also eDP panels. Additionally with this rename we will keep modparam and i915_params field name in sync. Finally this patch will unblock us with further improvements around params defs. Suggested-by: Ville Syrjala Signed-off-by:

[Intel-gfx] [PATCH v3 3/4] drm/i915: Highlight modified i915 params in gpu error state

We now know types and default values for all params. Use dedicated err_print macros to dump them in gpu error state and flag any that was modified. Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

Op 14-06-17 om 16:52 schreef Ville Syrjälä: > On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: >> Moving the wait to a helper allows callers outside of the core to >> wait for pending updates to complete. >> >> This can be used to prevent races against nonblocking modesets. >>

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

On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote: > intel_csr_load_program can fail (if not supported by SoC, or if file > is size 0) Those are really just sanity checks, they can't happen normally. We should actually convert them to be WARNs. > and theres no conditional that it

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

This is just missing the EXPORT_SYMBOL(drm_find_hdmi_output_type); Will handle this. Regards Shashank -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, June 14, 2017 11:22 PM To: Sharma, Shashank Cc:

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

== Series Details == Series: HDMI YCBCR output handling in DRM layer (rev3) URL : https://patchwork.freedesktop.org/series/22684/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h

[Intel-gfx] [PATCH v3 13/14] 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. Cc: Ville Syrjala Cc: Ander Conselvan De Oliveira

[Intel-gfx] [PATCH v3 14/14] 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. Signed-off-by: Shashank Sharma ---

[Intel-gfx] [PATCH v3 12/14] 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 v3 10/14] 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 v3 11/14] 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 v3 04/14] 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 v3 05/14] drm: 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 Cc: Ville Syrjälä

[Intel-gfx] [PATCH v3 06/14] 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 v3 09/14] 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 v3 07/14] 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 v3 08/14] 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 v3 03/14] drm: add hdmi 2.0 source identifier

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

[Intel-gfx] [PATCH v3 02/14] 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 v3 01/14] 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 v3 00/14] 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] drm/i915: decouple runtime PM enablement from DMC presence

intel_csr_load_program can fail (if not supported by SoC, or if file is size 0) and theres no conditional that it succeeds before releasing power_put on POWER_DOMAIN_INIT, enabling runtime PM. As long as the driver *thinks* it has a valid path to a DMC firmware this will execute. "without DMC

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: decouple runtime PM enablement from DMC presence

== Series Details == Series: drm/i915: decouple runtime PM enablement from DMC presence URL : https://patchwork.freedesktop.org/series/25787/ State : failure == Summary == Series 25787v1 drm/i915: decouple runtime PM enablement from DMC presence

Re: [Intel-gfx] [PATCH 7/7] drm/i915: extract a _PICK2 macro

On Wed, Jun 14, 2017 at 8:16 AM, Ville Syrjälä wrote: > On Tue, Jun 13, 2017 at 04:33:50PM -0300, Paulo Zanoni wrote: >> Do it just like we do with _PICK and _PICK3, so our code looks a >> little more uniform. >> >> Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 7/7] drm/i915: extract a _PICK2 macro

Em Qua, 2017-06-14 às 18:16 +0300, Ville Syrjälä escreveu: > On Tue, Jun 13, 2017 at 04:33:50PM -0300, Paulo Zanoni wrote: > > Do it just like we do with _PICK and _PICK3, so our code looks a > > little more uniform. > > > > Signed-off-by: Paulo Zanoni > > --- > >  

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

On Wed, Jun 14, 2017 at 10:12:21AM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Runtime PM is disabled when DMC firmware is not present. Runtime PM is still > enabled even if DMC firmware fails to load. Hm, that would be a bug,

Re: [Intel-gfx] [PATCH 3/7] drm/i915: use variable arguments for the macros that call _PICK

On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni wrote: > There's no need to create a new macro every time the number of > parameters change. fully agree > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/i915_reg.h | 8 > 1

Re: [Intel-gfx] [PATCH 2/7] drm/i915: _MMIO_PORT3 takes a port as an argument

Although I'd prefer to kill it, this patch is right, so Reviewed-by: Rodrigo Vivi On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni wrote: > The macro takes a port as an argument, not a pipe. > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 1/7] drm/i915: reorder the register picking macros

Reviewed-by: Rodrigo Vivi On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni wrote: > We currently have pipe, plane, trans, port, pll and phy versions of > these macros. Reorder their definitions so all macros of each type are > in their own group,

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

From: Matt Atwood Runtime PM is disabled when DMC firmware is not present. Runtime PM is still enabled even if DMC firmware fails to load. This patch enables runtime PM to be enabled if DMC firmware is not present. Signed-off-by: Matt Atwood

[Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty

Can the following patch please be included in the next stable release? It looks like it was submitted previously by Daniel Vetter, but has not been included in 4.11.y yet. Thanks. From 64b1d89f358df34701d92471b65f99f4eff1b384 Mon Sep 17 00:00:00 2001 From: Chris Wilson

Re: [Intel-gfx] [PATCH 7/7] drm/i915: extract a _PICK2 macro

On Tue, Jun 13, 2017 at 04:33:50PM -0300, Paulo Zanoni wrote: > Do it just like we do with _PICK and _PICK3, so our code looks a > little more uniform. > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/i915_reg.h | 12 ++-- > 1 file changed, 6

Re: [Intel-gfx] [PATCH] drm/i915: fix the issue DP-1 not working in guest

For a virtualized boot, it is possible for port A to be tied to DP. Min He any additional comment? On Jun 14, 2017 9:38 PM, Ville Syrjälä wrote: On Wed, Jun 14, 2017 at 01:47:30PM +0800, Mustamin B Mustaffa wrote: > From: "Anuar, Nuhairi"

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: > Moving the wait to a helper allows callers outside of the core to > wait for pending updates to complete. > > This can be used to prevent races against nonblocking modesets. > Only the hw_done call in swap_state is moved to a

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote: > In a IGD passthrough environment, the real ISA bridge may doesn't exist. > then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is > used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as > LPT_H,then

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

On Wed, Jun 14, 2017 at 11:08:42AM +0200, Maarten Lankhorst wrote: > The nonblocking modeset tests were failing on systems with a DP output, > because lijnk training could occur during the modeset. > > With normal modesets we're protected by the connection_mutex lock, > but nonblocking modesets

Re: [Intel-gfx] [PATCH] drm/i915: fix the issue DP-1 not working in guest

On Wed, Jun 14, 2017 at 01:47:30PM +0800, Mustamin B Mustaffa wrote: > From: "Anuar, Nuhairi" > > In GVT guest, when port A is DP, i915 will force it as an EDP panel, > which > will cause DP-1 not working in GVT guest. > This patch fixed this issue by check

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

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 considered for the CI topic branch,

Re: [Intel-gfx] [PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

On 13/06/2017 14:47, Colin King wrote: From: Colin Ian King The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global scope, so make it static. Cleans up sparse warning: "symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it be static?"

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

HI, > -Original Message- > == Series Details == > > Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment > URL : https://patchwork.freedesktop.org/series/25772/ > State : success > > == Summary == > > Series 25772v1 drm/i915: Setting pch_id for HSW/BDW in virtual >

[Intel-gfx] [PATCH i-g-t] tests/chamelium: Set output pipe after mode change to refresh output

This adds a call to igt_output_set_pipe in orde to refresh output via igt_output_refresh and ensure that mode override can take effect. Without this change, using a lower resolution during frame dumps series with mode changes (e.g. test_display_frame_dump) would not commit the mode change to the

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote: > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper > wrote: > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote: > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b. > > > > > > New ddb

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

== Series Details == Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment URL : https://patchwork.freedesktop.org/series/25772/ State : success == Summary == Series 25772v1 drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

In a IGD passthrough environment, the real ISA bridge may doesn't exist. then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as LPT_H,then errors occur when i915 runs on LPT_LP machines with igd passthrough.

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

On Wed, 2017-06-14 at 10:51 +0300, Paul Kocialkowski wrote: > On Wed, 2017-06-14 at 10:47 +0300, Paul Kocialkowski wrote: > > Hi, > > > > On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote: > > > NAK, igt_hpd_storm_set_threshold is expected to be called in both > > > situations with and without

[Intel-gfx] [i-g-t PATCH v4 2/2] Convert tools shell tests to C version

v4: Go thru /dev/kmsg instead of doing "dmesg | grep ..." (Arek). Split conversion to couple of patches. Converted: - sysfs_l3_parity - test_rte_check (same as check_drm_clients) - tools_test - ZZ_check_dmesg Signed-off-by: Abdiel Janulgue

[Intel-gfx] [i-g-t v4 PATCH 1/2] Convert debugfs shell tests to C version

v4: Rename get_sysfs_entry -> read_and_discard_sysfs_entry, assert on null igt_sysfs_get() (Arek). v3: Drop redundant test covered by drv_hangman/basic. Descend thru debugfs path when reading sysfs entries (Chris). v2: Use internal igt_debugfs functions instead of cat and document

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

Quoting Joonas Lahtinen (2017-06-13 15:07:04) > On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote: > > When we are called to relieve mempressue via the shrinker, the only way > > we can make progress is either by discarding unwanted pages (those > > objects that userspace has marked

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Close DRM file descriptor after tests

On Wed, 2017-06-14 at 10:36 +0100, Chris Wilson wrote: > Quoting Paul Kocialkowski (2017-06-12 16:21:45) > > On Mon, 2017-06-12 at 17:39 +0300, Paul Kocialkowski wrote: > > > This adds a call to close the DRM file descriptor. It is reauired as IGT > > > will attempt to become DRM master after

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

>-Original Message- >From: Zhenyu Wang [mailto:zhen...@linux.intel.com] >Sent: Wednesday, June 14, 2017 5:39 PM >To: Chen, Xiaoguang >Cc: alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk; >intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

On 2017.06.09 14:50:39 +0800, Xiaoguang Chen wrote: > decode frambuffer attributes of primary, cursor and sprite plane > > Signed-off-by: Xiaoguang Chen ... > +/** > + * intel_vgpu_decode_primary_plane - Decode primary plane > + * @vgpu: input vgpu > + * @plane:

Re: [Intel-gfx] [PATCH] drm/i915/selftests: silence a bogus spammy warning

On Wed, Jun 14, 2017 at 10:29:57AM +0100, Chris Wilson wrote: > Quoting Dan Carpenter (2017-06-14 10:14:52) > > These tests are reversed so it complains on every successful call and > > stays quiet for every failure. Also we may as well preserve the error > > code. > > The test is correct. The

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Close DRM file descriptor after tests

Quoting Paul Kocialkowski (2017-06-12 16:21:45) > On Mon, 2017-06-12 at 17:39 +0300, Paul Kocialkowski wrote: > > This adds a call to close the DRM file descriptor. It is reauired as IGT > > will attempt to become DRM master after running the test, resulting in a > > failure. > > This should fix

Re: [Intel-gfx] [PATCH] drm/i915/selftests: silence a bogus spammy warning

Quoting Dan Carpenter (2017-06-14 10:14:52) > These tests are reversed so it complains on every successful call and > stays quiet for every failure. Also we may as well preserve the error > code. The test is correct. The expectation here is that i915_gem_object_ggtt_pin() fails and reports

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/atomic: move waiting for hw_done to a helper

== Series Details == Series: series starting with [v2,1/2] drm/atomic: move waiting for hw_done to a helper URL : https://patchwork.freedesktop.org/series/25761/ State : success == Summary == Series 25761v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915/selftests: silence a bogus spammy warning

These tests are reversed so it complains on every successful call and stays quiet for every failure. Also we may as well preserve the error code. Fixes: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction") Signed-off-by: Dan Carpenter --- Static

[Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

Moving the wait to a helper allows callers outside of the core to wait for pending updates to complete. This can be used to prevent races against nonblocking modesets. Only the hw_done call in swap_state is moved to a helper, doing it for the other callers requires too many changes and I think

[Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

The nonblocking modeset tests were failing on systems with a DP output, because lijnk training could occur during the modeset. With normal modesets we're protected by the connection_mutex lock, but nonblocking modesets drop locks before completing. To get around that, check if the most recent

[Intel-gfx] [PATCH i-g-t] tests/kms_cursor_crc: Fix the cursor tests to work on CHV

On CHV pipe C when the cursor is visible with a negative X coordinate a FIFO Underrun will occur. The kernel worked around this by disallowing cursor updates on pipe C at negative X coordinates when the cursor is visible. This was done in the following kernel commit: commit

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

On Wed, 2017-06-14 at 10:47 +0300, Paul Kocialkowski wrote: > Hi, > > On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote: > > NAK, igt_hpd_storm_set_threshold is expected to be called in both > > situations with and without hpd storm control support. The function > > should be able to notice

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

Hi, On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote: > NAK, igt_hpd_storm_set_threshold is expected to be called in both > situations with and without hpd storm control support. The function > should be able to notice when the host doesn't have the debugfs nodes > for hpd storm control, and

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check if WM is greater than previous level

Please ignore this patch. The owner will upstream this patch himself. -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, June 14, 2017 1:56 PM To: Mustaffa, Mustamin B Cc: intel-gfx@lists.freedesktop.org Subject:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix the issue DP-1 not working in guest

== Series Details == Series: drm/i915: fix the issue DP-1 not working in guest URL : https://patchwork.freedesktop.org/series/25753/ State : success == Summary == Series 25753v1 drm/i915: fix the issue DP-1 not working in guest