[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/18] drm/i915/cnl: Implement .get_display_clock_speed() for CNL

== Series Details == Series: series starting with [01/18] drm/i915/cnl: Implement .get_display_clock_speed() for CNL URL : https://patchwork.freedesktop.org/series/25592/ State : success == Summary == Series 25592v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

== Series Details == Series: drm/core: Fail atomic IOCTL with no CRTC state but with signaling. URL : https://patchwork.freedesktop.org/series/25591/ State : success == Summary == Series 25591v1 drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Re: [Intel-gfx] [PATCH] drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

On Fri, 2017-06-09 at 15:02 -0700, Rodrigo Vivi wrote: > All here is pretty much like Kabylake. > > Including CFL-U has to use same ddi translation table > as KBL-U for now. > > v2: Include missed IS_COFFEELAKE on edp trans table. (DK) > Handle CFL-U with same translation table as KBL-U. (DK

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add MMIO helper for 6 ports with different offsets.

On Fri, Jun 09, 2017 at 03:26:05PM -0700, Rodrigo Vivi wrote: > Also new registers can have different mmio offsets > per different lane per port. > > v2: Use _PICK as PORT3 instead of creating a new > macro with if per port. > v3: Use _PICK directly on MMIO_PORT6. While MMIO_PORT > isn't

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cfl: Basic DDI plumbing for Coffee Lake. (rev3)

== Series Details == Series: drm/i915/cfl: Basic DDI plumbing for Coffee Lake. (rev3) URL : https://patchwork.freedesktop.org/series/25579/ State : success == Summary == Series 25579v3 drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

[Intel-gfx] [PATCH 07/18] drm/i915/cnl: Initialize PLLs

Although CNL follows PLL initialization more like Skylake than Broxton we have a completely different initialization sequence and registers used. One big difference from SKL is that CDCLK PLL is now exclusive (ADPLL) and for DDIs and MIPI we need to use DFGPLLs 0, 1 or 2. v2: Accept all Ander's

[Intel-gfx] [PATCH 05/18] drm/i915/cnl: DDI - PLL mapping

One of the steps for PLL (un)initialization is to (un)map the correspondent DDI that is actually using that PLL. So, let's do this step following the places already stablished and used so far, although spec put this as part of PLL initialization sequences. v2: Use proper prefix on bits names as

[Intel-gfx] [PATCH 04/18] drm/i915/cnl: Allow dynamic cdclk changes on CNL

All the low level cdclk bits are present, so let's add the required hooks to reconfigure cdclk on the fly. Cannonlake also needs to adjust the minimal pixel rate as gen9 platforms. Specially for the Azalia audio case. v2: Rebase due to cnl_sanitize_cdclk() v3: Rebased by Rodrigo on top of

[Intel-gfx] [PATCH 13/18] drm/i915/DMC/CNL: Load DMC on CNL

From: Anusha Srivatsa This patch loads the DMC on CNL.The firmware version is 1.04. v2: (Rodrigo) Remove MODULE_FIRMWARE. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 03/18] drm/i915/cnl: Implement CNL display init/unit sequence

From: Ville Syrjälä Implement the CNL display init/uninit sequence as outlined in Bspec. Quite similar to SKL/BXT. The main complicaiton is probably the extra procmon setup we must do based on the process/voltage information we can read out from some register.

[Intel-gfx] [PATCH 16/18] drm/i915/cnl: Enable fifo underrun for Cannonlake.

Also in a way that reuse bdw+ for all next platforms. Signed-off-by: Rodrigo Vivi Reviewed-by: Mika Kahola --- drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 11/18] drm/i915/cnl: Implement voltage swing sequence.

This is an important part of the DDI initalization as well as for changing the voltage during DisplayPort link training. This new sequence for Cannonlake is more like Broxton style but still with different registers, different table and different steps. v2: Do not write to DW4_GRP to avoid

[Intel-gfx] [PATCH 09/18] drm/i915/cnl: Add registers related to voltage swing sequences.

This are the registers and bits needed for the voltage swing sequence on Cannonlake. v2: Remove CL_DW5 that was wrongly defined. v3: Use (1 << 1) instead of (1<<1) as Paulo suggested Change DW2 swing sel upper and lower macros to do the bit selection instead of definint a table that

[Intel-gfx] [PATCH 08/18] drm/i915: Add MMIO helper for 6 ports with different offsets.

Also new registers can have different mmio offsets per different lane per port. v2: Use _PICK as PORT3 instead of creating a new macro with if per port. v3: Use _PICK directly on MMIO_PORT6. While MMIO_PORT isn't flexible enough let's continue with MMIO_PORT6 as we have MMIO_PORT3.

[Intel-gfx] [PATCH 10/18] drm/i915/cnl: Add DDI Buffer translation tables for Cannonlake.

These tables are used on voltage wswing sequence initialization on Cannonlake. It is a complete new format now in use by the voltage swing team, not following any other standard in use by any other platform. Also the registers are different as well. So let's redefine the translation table for

[Intel-gfx] [PATCH 14/18] drm/i915: Use HAS_CSR instead of gen number on DMC load.

Since we have HAS_CSR tied to the platform definition let's use this instead of checking per platform. One less thing to worry when adding support to new platforms. Signed-off-by: Rodrigo Vivi Reviewed-by: Animesh Manna ---

[Intel-gfx] [PATCH 12/18] drm/i915/cnl: Enable loadgen_select bit for vswing sequence

From: Clint Taylor vswing programming sequence step 2 requires the Loadgen_select bit to be set in PORT_TX_DW4 lane reigsters per table defined by Bit rate and lane width. Implemented the change that was marked as FIXME in the driver. v2: (Rodrigo) checkpatch fixes.

[Intel-gfx] [PATCH 18/18] drm/i915/cnl: Enable wrpll computation for CNL

From: "Kahola, Mika" Enable wrpll computation for Cannonlake platform to support pll's required for HDMI output. The patch contains the following features - compute Cannonlake port clock programming dividers P, Q, and K. - compute PLL parameters for Cannonlake. These

[Intel-gfx] [PATCH 02/18] drm/i915/cnl: Implement .set_cdclk() for CNL

From: Ville Syrjälä Add support for changing the cdclk frequency on CNL. Again, quite similar to BXT, but there are some annoying differences which means trying to share more code might not be feasible: * PLL ratio now lives in the PLL enable register * pcode came

[Intel-gfx] [PATCH 06/18] drm/i915: Configure DPLL's for Cannonlake

From: "Kahola, Mika" DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these definitions when computing dpll's for ddi ports. v2: (Rodrigo) Remove register that was defined in another patch with fixed name and more bits. Signed-off-by: Kahola, Mika

[Intel-gfx] [PATCH 01/18] drm/i915/cnl: Implement .get_display_clock_speed() for CNL

From: Ville Syrjälä Add support for reading out the cdclk frequency from the hardware on CNL. Very similar to BXT, with a few new twists and turns: * the PLL is now called CDCLK PLL, not DE PLL * reference clock can be 24 MHz in addition to the 19.2 MHz BXT had *

[Intel-gfx] [PATCH 17/18] drm/i915/cnl: LSPCON support is gen9+

There is no platform specific change needed for LSPCON support on Cannonlake. So let's make it gen9+. Cc: Shashank Sharma Signed-off-by: Rodrigo Vivi Reviewed-by: Shashank Sharma --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 15/18] drm/i915/cnl: Fix Cannonlake scaler mode programing.

As Geminilake scalers Cannonlake also don't need and don't have the "high quality" mode programming. Cc: Ander Conselvan de Oliveira Signed-off-by: Rodrigo Vivi Reviewed-by: Ville Syrjälä ---

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

Paulo Zanoni writes: > Em Sex, 2017-06-09 às 22:40 +0300, Ville Syrjälä escreveu: >> On Fri, Jun 09, 2017 at 08:24:59PM +0100, Chris Wilson wrote: >> Just a random idea that popped to my head (probably not for the first >> time); I think the most informative option

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

Reviewed-by: Harry Wentland Harry On 2017-06-09 05:13 PM, sunpeng...@amd.com wrote: > From: "Leo (Sunpeng) Li" > > Name should not be driver-specific. > > Signed-off-by: Leo (Sunpeng) Li > --- > lib/igt_kms.c |

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

Chris Wilson writes: > I just don't see the test case as being a good reason to claim the > kernel behaviour is broken. The kernel may report any of the reasons as > the one that caused FBC to be disabled (they are all valid, it is only > the order in which we test, or

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

Problem: While running IGT kms_atomic_transition test suite i encountered a hang in drmHandleEvent immidietly follwoing an atomic_commit. After dumping the atomic state I relized that in this case there was not even one CRTC attached to the state and only disabled planes. This probably due to a

[Intel-gfx] [PATCH] drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

All here is pretty much like Kabylake. Including CFL-U has to use same ddi translation table as KBL-U for now. v2: Include missed IS_COFFEELAKE on edp trans table. (DK) Handle CFL-U with same translation table as KBL-U. (DK and confirmed with HW engineers) v3: Adding missed case for

[Intel-gfx] [PATCH] drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

All here is pretty much like Kabylake. Including CFL-U has to use same ddi translation table as KBL-U for now. v2: Include missed IS_COFFEELAKE on edp trans table. (DK) Handle CFL-U with same translation table as KBL-U. (DK and confirmed with HW engineers) v3: Adding missed case for

Re: [Intel-gfx] [PATCH] drm/i915/cfl: Coffee Lake reuses Kabylake DMC.

patch merged to dinq. Thanks for the review. On Fri, Jun 9, 2017 at 1:02 PM, Rodrigo Vivi wrote: > both platforms. We haven't recieved any separated release > specifically for Coffee Lake so let's just re-use what > is already there for Kabylake. > > Signed-off-by:

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Increase value of I915_MAX_PIPES to 6

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of sunpeng...@amd.com > Sent: Friday, June 09, 2017 4:18 PM > To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org; > Wentland, Harry > Cc: Li, Sun peng > Subject: [PATCH i-g-t v2]

Re: [Intel-gfx] [PATCH] drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

On Fri, 2017-06-09 at 13:03 -0700, Rodrigo Vivi wrote: > All here is pretty much like Kabylake. > > Including CFL-U has to use same ddi translation table > as KBL-U for now. > > v2: Include missed IS_COFFEELAKE on edp trans table. (DK) > Handle CFL-U with same translation table as KBL-U. (DK

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, 2017-06-09 at 23:42 +0300, Imre Deak wrote: > On Fri, Jun 09, 2017 at 11:31:36PM +0300, Vivi, Rodrigo wrote: > > On Fri, 2017-06-09 at 23:21 +0300, Imre Deak wrote: > > > On Fri, Jun 09, 2017 at 11:01:17PM +0300, Vivi, Rodrigo wrote: > > > > On Fri, 2017-06-09 at 22:51 +0300, Imre Deak

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Increase value of I915_MAX_PIPES to 6

On 2017-06-09 04:17 PM, sunpeng...@amd.com wrote: > From: "Leo (Sunpeng) Li" > > Increasing max pipe count to 6 to support AMD GPU's. > > Since some tests' behavior depends on this value, small changes are made > to remove this dependency: > > * kms_ccs: Early abort if

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, Jun 09, 2017 at 11:31:36PM +0300, Vivi, Rodrigo wrote: > On Fri, 2017-06-09 at 23:21 +0300, Imre Deak wrote: > > On Fri, Jun 09, 2017 at 11:01:17PM +0300, Vivi, Rodrigo wrote: > > > On Fri, 2017-06-09 at 22:51 +0300, Imre Deak wrote: > > > > On Fri, Jun 09, 2017 at 10:32:54PM +0300, Ville

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

== Series Details == Series: drm/i915/cfl: Basic DDI plumbing for Coffee Lake. URL : https://patchwork.freedesktop.org/series/25579/ State : success == Summary == Series 25579v1 drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, 2017-06-09 at 23:21 +0300, Imre Deak wrote: > On Fri, Jun 09, 2017 at 11:01:17PM +0300, Vivi, Rodrigo wrote: > > On Fri, 2017-06-09 at 22:51 +0300, Imre Deak wrote: > > > On Fri, Jun 09, 2017 at 10:32:54PM +0300, Ville Syrjälä wrote: > > > > On Fri, Jun 09, 2017 at 10:02:09PM +0300, Imre

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, Jun 09, 2017 at 11:01:17PM +0300, Vivi, Rodrigo wrote: > On Fri, 2017-06-09 at 22:51 +0300, Imre Deak wrote: > > On Fri, Jun 09, 2017 at 10:32:54PM +0300, Ville Syrjälä wrote: > > > On Fri, Jun 09, 2017 at 10:02:09PM +0300, Imre Deak wrote: > > > > On Fri, Jun 09, 2017 at 05:34:55PM +0300,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cfl: Coffee Lake reuses Kabylake DMC.

== Series Details == Series: drm/i915/cfl: Coffee Lake reuses Kabylake DMC. URL : https://patchwork.freedesktop.org/series/25578/ State : success == Summary == Series 25578v1 drm/i915/cfl: Coffee Lake reuses Kabylake DMC.

[Intel-gfx] [PATCH] drm/i915/cfl: Basic DDI plumbing for Coffee Lake.

All here is pretty much like Kabylake. Including CFL-U has to use same ddi translation table as KBL-U for now. v2: Include missed IS_COFFEELAKE on edp trans table. (DK) Handle CFL-U with same translation table as KBL-U. (DK and confirmed with HW engineers) Cc: Dhinakaran Pandiyan

[Intel-gfx] [PATCH] drm/i915/cfl: Coffee Lake reuses Kabylake DMC.

both platforms. We haven't recieved any separated release specifically for Coffee Lake so let's just re-use what is already there for Kabylake. Signed-off-by: Rodrigo Vivi Reviewed-by: Dhinakaran Pandiyan ---

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, 2017-06-09 at 22:51 +0300, Imre Deak wrote: > On Fri, Jun 09, 2017 at 10:32:54PM +0300, Ville Syrjälä wrote: > > On Fri, Jun 09, 2017 at 10:02:09PM +0300, Imre Deak wrote: > > > On Fri, Jun 09, 2017 at 05:34:55PM +0300, Ville Syrjälä wrote: > > > > On Thu, Jun 08, 2017 at 03:03:13PM -0700,

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

Em Sex, 2017-06-09 às 22:40 +0300, Ville Syrjälä escreveu: > On Fri, Jun 09, 2017 at 08:24:59PM +0100, Chris Wilson wrote: > > Quoting Gabriel Krisman Bertazi (2017-06-01 16:36:08) > > > If the atomic commit doesn't include any new plane, there is no > > > need to > > > choose a new CRTC for FBC,

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, Jun 09, 2017 at 10:32:54PM +0300, Ville Syrjälä wrote: > On Fri, Jun 09, 2017 at 10:02:09PM +0300, Imre Deak wrote: > > On Fri, Jun 09, 2017 at 05:34:55PM +0300, Ville Syrjälä wrote: > > > On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > > > > All the low level cdclk bits

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

On Fri, Jun 09, 2017 at 08:24:59PM +0100, Chris Wilson wrote: > Quoting Gabriel Krisman Bertazi (2017-06-01 16:36:08) > > If the atomic commit doesn't include any new plane, there is no need to > > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out > > early. Although, if

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

Em Sex, 2017-06-09 às 20:24 +0100, Chris Wilson escreveu: > Quoting Gabriel Krisman Bertazi (2017-06-01 16:36:08) > > If the atomic commit doesn't include any new plane, there is no > > need to > > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will > > bail out > > early.  Although,

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, 2017-06-09 at 22:02 +0300, Imre Deak wrote: > On Fri, Jun 09, 2017 at 05:34:55PM +0300, Ville Syrjälä wrote: > > On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > > > All the low level cdclk bits are present, so let's add the required > > > hooks to reconfigure cdclk on the

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, Jun 09, 2017 at 10:02:09PM +0300, Imre Deak wrote: > On Fri, Jun 09, 2017 at 05:34:55PM +0300, Ville Syrjälä wrote: > > On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > > > All the low level cdclk bits are present, so let's add the required > > > hooks to reconfigure cdclk

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

Quoting Gabriel Krisman Bertazi (2017-06-01 16:36:08) > If the atomic commit doesn't include any new plane, there is no need to > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out > early. Although, if the FBC setup failed in the previous commit, if the > current commit

Re: [Intel-gfx] [PATCH 2/2] drm/i915/huc: Load HuC on Coffee Lake

Patches merged to dinq. Thanks for the patches and review. On Fri, Jun 9, 2017 at 5:03 AM, Fiedorowicz, Lukasz wrote: > On Thu, 2017-06-08 at 16:48 -0700, Anusha Srivatsa wrote: >> Coffee Lake reuses Kabylake's HUC firmware. >> >> v2: Change Coffeelake to Coffee

[Intel-gfx] [maintainer-tools PATCH] drm-intel: Fix small typo.

I noticed when resolving a conflict that reappeared. Signed-off-by: Rodrigo Vivi --- drm-intel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm-intel.rst b/drm-intel.rst index c9c8812..4699171 100644 --- a/drm-intel.rst +++ b/drm-intel.rst @@

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, Jun 09, 2017 at 05:34:55PM +0300, Ville Syrjälä wrote: > On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > > All the low level cdclk bits are present, so let's add the required > > hooks to reconfigure cdclk on the fly. > > > > v2: Rebase due to cnl_sanitize_cdclk() > > v3:

Re: [Intel-gfx] [PATCH 3/3] drm/i915/cfl: Add Coffee Lake PCI IDs for U Sku.

Patches merged to dinq. Thanks for the patches. On Thu, Jun 8, 2017 at 4:50 PM, Vivi, Rodrigo wrote: > > Reviewed-by: Rodrigo Vivi > > On Thu, 2017-06-08 at 16:41 -0700, Anusha Srivatsa wrote: >> Add PCI Ids for U Skus of Coffeelake. >> >> v2: Use

Re: [Intel-gfx] [PATCH v16 15/17] drm/i915/perf: allow NOA muxes reprogramming before workloads

On 5 June 2017 at 15:48, Lionel Landwerlin wrote: > Dynamic slices/subslices shutdown will effectivelly loose the NOA > configuration uploaded in the slices/subslices. > > Here we introduce a new parameter to configure the i915 perf driver > when userspace wants to

Re: [Intel-gfx] [PATCH v16 16/17] drm/i915/perf: notify sseu configuration changes

On 5 June 2017 at 15:48, Lionel Landwerlin wrote: > This adds the ability for userspace to request that the kernel track & > record sseu configuration changes. These changes are inserted into the > perf stream so that userspace can interpret the OA reports using the

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Fri, 2017-06-09 at 17:34 +0300, Ville Syrjälä wrote: > On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > > All the low level cdclk bits are present, so let's add the required > > hooks to reconfigure cdclk on the fly. > > > > v2: Rebase due to cnl_sanitize_cdclk() > > v3: Rebased

Re: [Intel-gfx] [i-g-t] igt/gem_reset_stats: Fix pending batches status expectation

On 6/9/2017 10:02 AM, Antonio Argenziano wrote: Test expects pending batches to be discarded after a reset. That is no longer the case. Fixed to expect a normal execution. You could expand this to say: after commit 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests"), that

[Intel-gfx] [i-g-t] igt/gem_reset_stats: Fix pending batches status expectation

Test expects pending batches to be discarded after a reset. That is no longer the case. Fixed to expect a normal execution. Cc: Michel Thierry Signed-off-by: Antonio Argenziano --- tests/gem_reset_stats.c | 24 +++- 1

Re: [Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.19

Is there an update for xf86-video-intel on the way? The last release is version 2.99.917, released in 2014. This is pretty frustrating for OSes and distributions who want to include updated drivers. Thanks! On 2017 Jun 09 (Fri) at 16:51:13 +0300 (+0300), Petri Latvala wrote: : :A new

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > All the low level cdclk bits are present, so let's add the required > hooks to reconfigure cdclk on the fly. > > v2: Rebase due to cnl_sanitize_cdclk() > v3: Rebased by Rodrigo on top of Ville's cdclk rework. > v4: Rebase moving

[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.19

A new intel-gpu-tools quarterly release is available with the following changes: Library changes: - Changed debugfs handlers to open files for the DRM device in use, for setups with more than one DRM device. (Tomeu Vizoso) - Added support for 4K and audio HDMI EDID injection. (Abdiel

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

On Fri 09-06-17 12:51:57, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-09 12:17:26) > > [Add Hugh] > > > > On Fri 09-06-17 12:03:50, 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

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_properties.c: fix test case for setting immutable properties

On 2017-06-09 08:22 AM, Arkadiusz Hiler wrote: > On Thu, Jun 08, 2017 at 04:06:44PM -0400, Bhawanpreet Lakha wrote: >> Test doesn't check if the property is immutable, and fails. >> Added conditions to detect if the property is immutable. >> >> Signed-off-by: Bhawanpreet Lakha

Re: [Intel-gfx] [PATCH 04/17] drm/i915/cnl: Allow dynamic cdclk changes on CNL

On Thu, Jun 08, 2017 at 03:03:13PM -0700, Rodrigo Vivi wrote: > All the low level cdclk bits are present, so let's add the required > hooks to reconfigure cdclk on the fly. > > v2: Rebase due to cnl_sanitize_cdclk() > v3: Rebased by Rodrigo on top of Ville's cdclk rework. > v4: Rebase moving

Re: [Intel-gfx] [PATCH 0/4] Cleanups and fixes

On Fri, Jun 09, 2017 at 03:37:54PM +0300, Arkadiusz Hiler wrote: > On Fri, Jun 09, 2017 at 03:34:42PM +0300, Arkadiusz Hiler wrote: > > On Mon, Jun 05, 2017 at 02:28:36PM +0100, Liviu Dudau wrote: > > > From: Liviu Dudau > > > > > > Hello, > > > > > > I believe Brian has

Re: [Intel-gfx] [PATCH 0/4] Cleanups and fixes

On Fri, Jun 09, 2017 at 03:34:42PM +0300, Arkadiusz Hiler wrote: > On Mon, Jun 05, 2017 at 02:28:36PM +0100, Liviu Dudau wrote: > > From: Liviu Dudau > > > > Hello, > > > > I believe Brian has sent these patches before, but he did not had any > > luck getting them accepted,

Re: [Intel-gfx] [PATCH 0/4] Cleanups and fixes

On Mon, Jun 05, 2017 at 02:28:36PM +0100, Liviu Dudau wrote: > From: Liviu Dudau > > Hello, > > I believe Brian has sent these patches before, but he did not had any > luck getting them accepted, so it is now my turn :) > > These fixes were found while developing code for

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_properties.c: fix test case for setting immutable properties

On Thu, Jun 08, 2017 at 04:06:44PM -0400, Bhawanpreet Lakha wrote: > Test doesn't check if the property is immutable, and fails. > Added conditions to detect if the property is immutable. > > Signed-off-by: Bhawanpreet Lakha > --- > tests/kms_properties.c | 6 +- >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Remove the alpha_support flag

On Fri, 2017-06-09 at 08:43 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/glk: Remove the alpha_support flag > URL : https://patchwork.freedesktop.org/series/25471/ > State : failure > > == Summary == > > Series 25471v1 drm/i915/glk: Remove the alpha_support flag >

Re: [Intel-gfx] [PATCH i-g-t 1/4] intel-ci: Add comments on test order to fast-feedback.testlist

On Fri, Jun 09, 2017 at 02:39:28PM +0300, Petri Latvala wrote: > Document the test ordering choices in fast-feedback.testlist. > > For comments in testlists, piglit commit > > commit 0c535186d624071098c10003fdafe8f475ed9ae7 > Author: Petri Latvala > Date: Wed Feb 1

Re: [Intel-gfx] [PATCH 2/2] drm/i915/huc: Load HuC on Coffee Lake

On Thu, 2017-06-08 at 16:48 -0700, Anusha Srivatsa wrote: > Coffee Lake reuses Kabylake's HUC firmware. > > v2: Change Coffeelake to Coffee Lake > > Cc: Rodrigo Vivi > Signed-off-by: Anusha Srivatsa Reviewed-by: Lukasz Fiedorowicz

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Load GuC on Coffee Lake

On Thu, 2017-06-08 at 16:48 -0700, Anusha Srivatsa wrote: > Coffee Lake reuses Kabylake's GuC. > > v2: Change Coffeelake to Coffee Lake > > Cc: Rodrigo Vivi > Signed-off-by: Anusha Srivatsa Reviewed-by: Lukasz Fiedorowicz

Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rps: Replace custom load function with dummy load

On Wed, Jun 07, 2017 at 04:29:59PM +0200, Radoslaw Szwichtenberg wrote: > Replaced custom load implementation with lib counterpart. > > Signed-off-by: Radoslaw Szwichtenberg > Cc: Chris Wilson > Cc: Arkadiusz Hiler

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/debugfs: Highlight modified i915 params

On Fri, 2017-06-09 at 10:27 +, Michal Wajdeczko wrote: > 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) > > Suggested-by: Chris

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

Quoting Michal Hocko (2017-06-09 12:17:26) > [Add Hugh] > > On Fri 09-06-17 12:03:50, 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 i-g-t] tests/pm_rps: Replace custom load function with dummy load

On Wed, 2017-06-07 at 16:29 +0200, Radoslaw Szwichtenberg wrote: > Replaced custom load implementation with lib counterpart. > > Signed-off-by: Radoslaw Szwichtenberg om> Reviewed-by: Lukasz Fiedorowicz -Lukasz

[Intel-gfx] [PATCH i-g-t 1/4] intel-ci: Add comments on test order to fast-feedback.testlist

Document the test ordering choices in fast-feedback.testlist. For comments in testlists, piglit commit commit 0c535186d624071098c10003fdafe8f475ed9ae7 Author: Petri Latvala Date: Wed Feb 1 12:57:45 2017 +0200 framework/programs/run.py: Allow comments in

[Intel-gfx] [PATCH i-g-t 4/4] intel-ci: Document the public CI results web page

Signed-off-by: Petri Latvala --- tests/intel-ci/README | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/intel-ci/README b/tests/intel-ci/README index ae92460..d17922e 100644 --- a/tests/intel-ci/README +++ b/tests/intel-ci/README @@ -24,6 +24,9 @@

[Intel-gfx] [PATCH i-g-t 2/4] tests/Makefile.am: Only ignore generated gitignore in gitignore

When generating the .gitignore file, use /.gitignore instead of .gitignore to not have it apply to subdirectories. Signed-off-by: Petri Latvala --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am

[Intel-gfx] [PATCH i-g-t 3/4] intel-ci: Have the directory included in the distributed tarballs

Signed-off-by: Petri Latvala --- configure.ac | 1 + tests/Makefile.am | 2 ++ tests/intel-ci/Makefile.am | 7 +++ 3 files changed, 10 insertions(+) create mode 100644 tests/intel-ci/Makefile.am diff --git a/configure.ac b/configure.ac index

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/5] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

== Series Details == Series: series starting with [v2,1/5] drm/i915: Encourage our shrinker more when our shmemfs allocations fails URL : https://patchwork.freedesktop.org/series/25553/ State : success == Summary == Series 25553v1 Series without cover letter

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

[Add Hugh] On Fri 09-06-17 12:03:50, 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 MADV_DONTNEED) or by reclaiming the > dirty objects via swap.

[Intel-gfx] ✓ Fi.CI.BAT: success for NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute (rev3)

== Series Details == Series: NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute (rev3) URL : https://patchwork.freedesktop.org/series/25472/ State : success == Summary == Series 25472v3 NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: Remove __GFP_NORETRY from our buffer allocator

On Fri 09-06-17 12:03:47, Chris Wilson wrote: > I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It > struggles with handling reclaim of our dirty buffers and relies on > reclaim via kswapd. As a result, a single pass of direct reclaim is > unreliable when i915 occupies the

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

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 MADV_DONTNEED) or by reclaiming the dirty objects via swap. As we know that is the only way to make further progress, we can

[Intel-gfx] [PATCH v2 2/5] drm/i915: Remove __GFP_NORETRY from our buffer allocator

I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It struggles with handling reclaim of our dirty buffers and relies on reclaim via kswapd. As a result, a single pass of direct reclaim is unreliable when i915 occupies the majority of available memory, and the only means of

[Intel-gfx] [PATCH v2 3/5] drm/i915: Only restrict noreclaim in the early shrink passes

In our first pass, we do not want to use reclaim at all as we want to solely reap the i915 buffer caches (its purgeable pages). But we don't mind it initiates IO or pulls via the FS (but it shouldn't anyway as we say no to reclaim!). Just drop the GFP_IO constraint for simplicity. Signed-off-by:

[Intel-gfx] [PATCH v2 4/5] drm/i915: Spin for struct_mutex inside shrinker

Having resolved whether or not we would deadlock upon a call to mutex_lock(>struct_mutex), we can then spin for the contended struct_mutex if we are not the owner. We cannot afford to simply block and wait for the mutex, as the owner may itself be waiting for the allocator -- i.e. a cyclic

[Intel-gfx] [PATCH v2 1/5] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

Commit 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") made the bold decision to try and avoid the oomkiller by reporting -ENOMEM to userspace if our allocation failed after attempting to free enough buffer objects. In short, it appears we were

[Intel-gfx] [PATCH v3] NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute

I would like to send this patch to the core-for-CI branch, in order to verify the theory I exposed in fdo#101246. This patch also hides a potentially serious bug in the sound/hda driver, which may improve our chances of not being affected by bugs there. It may actually also fix some of the

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

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

[Intel-gfx] [PATCH v2 3/3] 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) Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v2 2/3] 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 v2 1/3] 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 v2 0/3] 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 Michal Wajdeczko (3): drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc drm/i915: Extend PARAMS_FOR_EACH macro with more data

[Intel-gfx] [PATCH] lib/igt_draw: Add Y-tiling support

This patch adds Y-tiling support for igt_draw_rect function. v2: Use helper function to get tile sizes (Ville) v3: Moved igt_get_fb_tile_size() out of the for loop for better performance (Paulo) Signed-off-by: Praveen Paneri --- lib/igt_draw.c | 139

[Intel-gfx] [PATCH i-g-t] igt/kms_properties.c: fix test case for setting immutable properties

Test doesn't check if the property is immutable, and fails. Added conditions to detect if the property is immutable. Signed-off-by: Bhawanpreet Lakha --- tests/kms_properties.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH igt] Revert "kms_cursor_legacy: Add a burner thread to make basic-busy-* pass."

Quoting Martin Peres (2017-06-07 12:05:14) > On 07/06/17 13:34, Chris Wilson wrote: > > This reverts commit 7c8703fb02b248c2bcf9756bba8812bcfe7ed5d3. > > > > If we expect it to fail until we find a solution, let the hw fail and > > continue to track the known failure in CI/bugs. > > > > Cc:

Re: [Intel-gfx] [PATCH i-g-t] tests: Increase value of I915_MAX_PIPES to 6

On Thu, Jun 08, 2017 at 09:48:58PM +, Deucher, Alexander wrote: > > -Original Message- > > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > > Of sunpeng...@amd.com > > Sent: Thursday, June 08, 2017 3:11 PM > > To: intel-gfx@lists.freedesktop.org;

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Remove the alpha_support flag

== Series Details == Series: drm/i915/glk: Remove the alpha_support flag URL : https://patchwork.freedesktop.org/series/25471/ State : failure == Summary == Series 25471v1 drm/i915/glk: Remove the alpha_support flag https://patchwork.freedesktop.org/api/1.0/series/25471/revisions/1/mbox/

  1   2   >