[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: SKL/KBL/BXT cdclk stuff

== Series Details == Series: drm/i915: SKL/KBL/BXT cdclk stuff URL : https://patchwork.freedesktop.org/series/7169/ State : failure == Summary == Series 7169v1 drm/i915: SKL/KBL/BXT cdclk stuff http://patchwork.freedesktop.org/api/1.0/series/7169/revisions/1/mbox Test gem_exec_flush:

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Refresh cached DP port register value on resume

== Series Details == Series: drm/i915: Refresh cached DP port register value on resume URL : https://patchwork.freedesktop.org/series/7163/ State : failure == Summary == Series 7163v1 drm/i915: Refresh cached DP port register value on resume

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2)

On Fri, May 13, 2016 at 07:04:07PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks > (rev2) > URL : https://patchwork.freedesktop.org/series/7155/ > State : failure > > == Summary == > > Series 7155v2 drm/i915: Fix

[Intel-gfx] [PATCH 19/21] drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco

From: Ville Syrjälä Make bxt_set_cdclk() more readable by looking at current vs. target DE PLL vco to determine if the DE PLL needs disabling and/or enabling. We can also calculate the CD2X divider simply as (vco/cdclk) instead of depending on magic numbers. The

[Intel-gfx] [PATCH 18/21] drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk

From: Ville Syrjälä Now that we've read out the DE PLL vco and refclk, we can just use them in the cdclk calculation. While at it switch over to DIV_ROUND_CLOSEST(). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 21/21] drm/i915: Set BXT cdclk to minimum initially

From: Ville Syrjälä In case the driver is initialized without active displays, we should just drop the cdclk to the minimum frequency right off the bat. There might not be a modeset to drop it to the minimum late rafter all. With DMC supposedly we should always

[Intel-gfx] [PATCH 16/21] drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv

From: Ville Syrjälä We have need to know the DE PLL refclk and output frequency in various cdclk calculations, so let's store those in dev_priv. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 27

[Intel-gfx] [PATCH 06/21] drm/i915: Report the current DPLL0 vco on SKL/KBL

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 05/21] drm/i915: Actually read out DPLL0 vco on skl from hardware

From: Ville Syrjälä Currently we're trying to guess which lcpll vco frequency is used use based on the cdclk. That doesn't work for cdclk==540 since both vco frequencies can generate a 540 Mhz output. Let's stop guessing and just read the actual vco frequency from

[Intel-gfx] [PATCH 17/21] drm/i915: Update cached cdclk state from broxton_init_cdclk()

From: Ville Syrjälä Let's make sure our cached cdclk state is accurate right after broxton_init_cdclk() whether or not we end up changing the cdclk frequency. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 20/21] drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check

From: Ville Syrjälä Rather than having a BXT specific function to make sure the DE PLL is enabled after disabling DC6, let's just make sure the current cdclk is the same as what we last programmed. Having another check in bxt_display_core_init() almost immediately

[Intel-gfx] [PATCH 11/21] drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit

From: Ville Syrjälä SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice

[Intel-gfx] [PATCH 15/21] drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()

From: Ville Syrjälä Enabling and disalbing the DE PLL are two nice self contained operations, so let's move them into a few small helper functions. Makes it easier to see the forest from the trees in broxton_set_cdclk(). Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 14/21] drm/i915: Store cdclk PLL reference clock under dev_priv

From: Ville Syrjälä Future platforms will have multiple options for the cdclk PLL reference clock, so let's start tracking that under dev_priv alreday on SKL, although on SKL it's always 24 MHz. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 12/21] drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL

From: Ville Syrjälä The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz. Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz. Let's use the slightly more accurate numbers. Potentially we might change to computing all of these based on

[Intel-gfx] [PATCH 13/21] drm/i915: Rename skl_vco_freq to cdclk_pll.vco

From: Ville Syrjälä We'll want to store the cdclk PLL (whatever PLL that is in reality) vco frequency somewhere on other platforms too, so let's rename the skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz to match most of the other clocks.

[Intel-gfx] [PATCH 07/21] drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL

From: Ville Syrjälä In case we originally guessed wrong which lcpll vco frequency to use, we will need to shut down the pll and restart it when reprogamming the cdclk. This also allows us to track the actual vco frequency in dev_priv instead of just a guess.

[Intel-gfx] [PATCH 09/21] drm/i915: Beef up skl_sanitize_cdclk() a bit

From: Ville Syrjälä Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw out a few unneeded variables, and write the CDCLK_CTL check a bit more legible way. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 08/21] drm/i915: Keep track of preferred cdclk vco frequency on SKL

From: Ville Syrjälä Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need something that keeps track of which vco frequency we want to use in case the current vco is 0. This would be important across supend/resume since we'll disable DPLL0 around

[Intel-gfx] [PATCH 10/21] drm/i915: Unify SKL cdclk init paths

From: Ville Syrjälä Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we

[Intel-gfx] [PATCH 04/21] drm/i915: Extract skl_calc_cdclk()

From: Ville Syrjälä We have many places where we want to pick a suitable cdclk frequency for skl based on the dotclock and lcpll vco. Split that code into a small helper and call it from all over. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 03/21] drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config()

From: Ville Syrjälä Shared plls won't get assigned until the .compute_clocks() hook gets called, which happens from the crtc .atomic_check hook. That's too late as the cdclk computation has already happened. So let's move the DPLL0 VCO computation into

[Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout

From: Ville Syrjälä commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation") tried to change BXT to use ilk_max_pixel_rate() to compute the pipe pixel rate. I failed to notice that there was another place in the state readout code that

[Intel-gfx] [PATCH 02/21] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

From: Clint Taylor WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected to DDI1 the system will hard hang during a cold boot. Occurs when DDI1 is enabled when the cdclk is less then required. DP connected to DDI2 and HPD on either port works

[Intel-gfx] [PATCH 00/21] drm/i915: SKL/KBL/BXT cdclk stuff

From: Ville Syrjälä Here's my second installment of SKL+ cdclk stuff. I've picked up Clint's latest SKL/KBL cdclk patch and expanded on it quite a bit. After this series we're capable of actually changing the DPLL0 VCO frequency dynamically, and a lot of the code

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev7)

== Series Details == Series: series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev7) URL : https://patchwork.freedesktop.org/series/7063/ State : failure == Summary == Applying: drm/i915: Add distinct stubs for PM hibernation phases Applying: drm/i915: Update

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2)

== Series Details == Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2) URL : https://patchwork.freedesktop.org/series/7155/ State : failure == Summary == Series 7155v2 drm/i915: Fix for resume regression in ilk-bdw due to watermarks

Re: [Intel-gfx] [PATCH 00/13] drm/i915: cdclk code cleanup

On Wed, May 11, 2016 at 10:44:39PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here's a bunch of cleanup, refactoring, etc. of the cdclk code. Much of > this serves as prep work for a larger series I have lined up which > takes Clint's SKL

[Intel-gfx] [PATCH] drm/i915: Refresh cached DP port register value on resume

From: Ville Syrjälä During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw

On Fri, May 13, 2016 at 10:35:16AM -0700, Matt Roper wrote: > On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote: > > On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote: > > > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com > > > wrote: > > > > From:

[Intel-gfx] [CI 2/4] drm/i915: Update domain tracking for GEM objects on hibernation

When creating the hibernation image, the CPU will read the pages of all objects and thus conflict with our domain tracking. We need to update our domain tracking to accurately reflect the state on restoration. v2: Perform the domain tracking inside freeze, before the image is written, rather than

[Intel-gfx] [CI 3/4] drm/i915: Lazily migrate the objects after hibernation

Now that we mark the object domains for having been restored from the hibernation image, we not need to flush everything during resume and can instead rely on the normal domain tracking to flush only when required. The only caveat here are objects that are pinned for use by the hardware, whose

[Intel-gfx] [CI 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems

Under full-ppgtt, access to the global GTT is carefully regulated through hardware functions (i.e. userspace cannot read and write to arbitrary locations in the GGTT via the GPU). With this restriction in place, we can forgo clearing stale entries from the GGTT as they will not be accessed. For

[Intel-gfx] [CI 1/4] drm/i915: Add distinct stubs for PM hibernation phases

Currently for handling the extra hibernation phases we just call the equivalent suspend/resume phases. In the next couple of patches, I wish to specialise the hibernation phases to reduce the amount of work required for handling GEM objects. v2: There are more! Don't forget the freeze phases.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw

On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote: > On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote: > > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > When we resume

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw

On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote: > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > When we resume the watermark register may contain some BIOS leftovers, > > or just the

[Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)

From: Ville Syrjälä When we resume the watermark register may contain some BIOS leftovers, or just the hardware reset values. We should ignore those as the pipes will be off anyway, and so frobbing around with intermediate watermarks doesn't make much sense. In

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths

== Series Details == Series: drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths URL : https://patchwork.freedesktop.org/series/7158/ State : failure == Summary == Series 7158v1 drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw

On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > When we resume the watermark register may contain some BIOS leftovers, > or just the hardware reset values. We should ignore those as the > pipes will be off

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable GuC submission

== Series Details == Series: Enable GuC submission URL : https://patchwork.freedesktop.org/series/7153/ State : failure == Summary == Series 7153v1 Enable GuC submission http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/1/mbox Test drv_hangman: Subgroup

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks

== Series Details == Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks URL : https://patchwork.freedesktop.org/series/7155/ State : failure == Summary == CC drivers/usb/host/xhci-trace.o CC [M] drivers/video/fbdev/core/sysfillrect.o CC [M]

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev4)

== Series Details == Series: series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev4) URL : https://patchwork.freedesktop.org/series/7063/ State : failure == Summary == Applying: drm/i915: Add distinct stubs for PM hibernation phases Applying: drm/i915: Update

[Intel-gfx] ✗ Ro.CI.BAT: failure for Move dpio access out of intel_display.c

== Series Details == Series: Move dpio access out of intel_display.c URL : https://patchwork.freedesktop.org/series/7150/ State : failure == Summary == Series 7150v1 Move dpio access out of intel_display.c http://patchwork.freedesktop.org/api/1.0/series/7150/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH v4 2/7] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

On 13/05/16 15:36, Dave Gordon wrote: For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro

Re: [Intel-gfx] [PATCH v4 5/7] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 13/05/16 15:36, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a

Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter

On 13/05/16 15:36, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch

[Intel-gfx] [PATCH] drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths

From: Ville Syrjälä DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares about. However error paths everyone cares about, so hiding the error debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS for those instead. Signed-off-by:

[Intel-gfx] [PATCH igt] Revert "tests: Separate tests with lots of subtests"

This reverts commit a633ad03c6a0e96eecfd4933ea0dffb68ed40e07 as it completely breaks building the gem_concurrent_blit tests. --- tests/Makefile.am | 12 +++- tests/Makefile.sources | 22 ++ 2 files changed, 5 insertions(+), 29 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v4 1/7] drm/i915/guc: rename loader entry points

On 13/05/16 15:36, Dave Gordon wrote: The GuC initialisation code could do other things apart from loading firmware, so here we rename the three primary entry points to remove any specific reference to "ucode" (no functional changes, just renaming). Signed-off-by: Dave Gordon

Re: [Intel-gfx] [PATCH RESEND 2/2] drm/i915: don't mix bitwise and logical operations for has_snoop

On 13/05/16 15:04, Jani Nikula wrote: Also make the code more readable. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_dma.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c

Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

On 13/05/16 15:47, Jani Nikula wrote: On Fri, 13 May 2016, Chris Wilson wrote: On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote: On 13/05/16 15:04, Jani Nikula wrote: This is more robust for assignments and comparisons. Signed-off-by: Jani Nikula

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [RESEND,1/2] drm/i915: make device info bitfield flags bools

== Series Details == Series: series starting with [RESEND,1/2] drm/i915: make device info bitfield flags bools URL : https://patchwork.freedesktop.org/series/7149/ State : failure == Summary == Series 7149v1 Series without cover letter

[Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw

From: Ville Syrjälä When we resume the watermark register may contain some BIOS leftovers, or just the hardware reset values. We should ignore those as the pipes will be off anyway, and so frobbing around with intermediate watermarks doesn't make much sense. In

[Intel-gfx] [PATCH 1/2] drm/i915: Don't leave old junk in ilk active watermarks on readout

From: Ville Syrjälä When we read out the watermark state from the hardware we're supposed to transfer that into the active watermarks, but currently we fail to any part of the active watermarks that isn't explicitly written. Let's clear it all upfront. Looks like

[Intel-gfx] [PATCH 0/2] drm/i915: Fix for resume regression in ilk-bdw due to watermarks

From: Ville Syrjälä My ILK was very unhappy runnin BAT tests. Caused by watermark fail during resume. Here's the smallest fix I thought of. Ville Syrjälä (2): drm/i915: Don't leave old junk in ilk active watermarks on readout drm/i915: Ignore stale wm

Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

On Fri, 13 May 2016, Chris Wilson wrote: > On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote: >> >> On 13/05/16 15:04, Jani Nikula wrote: >> >This is more robust for assignments and comparisons. >> > >> >Signed-off-by: Jani Nikula >>

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Rename struct dpll to struct intel_dpll

On Fri, May 13, 2016 at 05:14:58PM +0300, Ander Conselvan de Oliveira wrote: > Prefix struct dpll with intel_ to follow the convention in the driver. > > Cc: Ville Syrjälä > Signed-off-by: Ander Conselvan de Oliveira > > ---

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for Pre-calculate SKL-style atomic watermarks (final CI run) (rev2)

On Thu, May 12, 2016 at 10:52:11PM +, Patchwork wrote: > == Series Details == > > Series: Pre-calculate SKL-style atomic watermarks (final CI run) (rev2) > URL : https://patchwork.freedesktop.org/series/7075/ > State : success Maarten confirmed on IRC that his r-b stands for the updated

[Intel-gfx] [PATCH v4 2/7] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro rather than HAS_GUC_UCODE() or testing

[Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter

Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In

[Intel-gfx] [PATCH v4 0/7] Enable GuC submission

This patchset covers various GuC-related changes, but most important of these are (1) splitting the original "enable_guc_submission" parameter into separate flags for loading GuC firmware vs. using the GuC for job submission [PATCH 3/7], and (2) actually enabling GuC submission by default on

[Intel-gfx] [PATCH v4 6/7] drm/i915/guc: rework guc_add_workqueue_item()

Mostly little optimisations and future-proofing against code breakage. For instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development

[Intel-gfx] [PATCH v4 7/7] drm/i915/guc: change default to using GuC submission if possible

This patch simply changes the default value of "enable_guc_submission" from 0 (never) to -1 (auto). This means that GuC submission will be used if the platform has a GuC, the GuC supports the request submission protocol, and any required GuC firmwware was successfully loaded. If any of these

[Intel-gfx] [PATCH v4 5/7] drm/i915/guc: don't spinwait if the GuC's workqueue is full

Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

On 10/05/16 15:37, Tvrtko Ursulin wrote: On 06/05/16 17:39, Dave Gordon wrote: On 29/04/16 16:03, Tvrtko Ursulin wrote: [snip] +goto fail; +if (fw_path == NULL) +goto fail; +if (*fw_path == '\0') { +DRM_ERROR("No GuC firmware known for this platform\n");

[Intel-gfx] [PATCH v4 4/7] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable

[Intel-gfx] [PATCH v4 1/7] drm/i915/guc: rename loader entry points

The GuC initialisation code could do other things apart from loading firmware, so here we rename the three primary entry points to remove any specific reference to "ucode" (no functional changes, just renaming). Signed-off-by: Dave Gordon ---

Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote: > > On 13/05/16 15:04, Jani Nikula wrote: > >This is more robust for assignments and comparisons. > > > >Signed-off-by: Jani Nikula > >--- > > drivers/gpu/drm/i915/i915_drv.h | 2 +- > > 1 file changed, 1

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Move CHV divider readout to intel_dpio_phy.c

On Fri, May 13, 2016 at 05:15:02PM +0300, Ander Conselvan de Oliveira wrote: > Reading the dividers depends on sideband messaging, so it fits well if > the other functions in intel_dpio_phy.c. The new function will also be > used in a future patch. > > Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [CI 1/4] drm/i915: Add distinct stubs for PM hibernation phases

Currently for handling the extra hibernation phases we just call the equivalent suspend/resume phases. In the next couple of patches, I wish to specialise the hibernation phases to reduce the amount of work required for handling GEM objects. v2: There are more! Don't forget the freeze phases.

[Intel-gfx] [CI 3/4] drm/i915: Lazily migrate the objects after hibernation

Now that we mark the object domains for having been restored from the hibernation image, we not need to flush everything during resume and can instead rely on the normal domain tracking to flush only when required. The only caveat here are objects that are pinned for use by the hardware, whose

[Intel-gfx] [CI 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems

Under full-ppgtt, access to the global GTT is carefully regulated through hardware functions (i.e. userspace cannot read and write to arbitrary locations in the GGTT via the GPU). With this restriction in place, we can forgo clearing stale entries from the GGTT as they will not be accessed. For

[Intel-gfx] [CI 2/4] drm/i915: Update domain tracking for GEM objects on hibernation

When creating the hibernation image, the CPU will read the pages of all objects and thus conflict with our domain tracking. We need to update our domain tracking to accurately reflect the state on restoration. v2: Perform the domain tracking inside freeze, before the image is written, rather than

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c

On Fri, May 13, 2016 at 05:15:03PM +0300, Ander Conselvan de Oliveira wrote: > This simplifies the pll enable/disable a code a bit and hides the > sideband message neatly in intel_dpio_phy.c. > > Signed-off-by: Ander Conselvan de Oliveira > > --- >

Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

On 13/05/16 15:04, Jani Nikula wrote: This is more robust for assignments and comparisons. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move VLV divider readout to intel_dpio_phy.c

On Fri, May 13, 2016 at 05:15:01PM +0300, Ander Conselvan de Oliveira wrote: > Reading the dividers depends on sideband messaging, so it fits well if > the other functions in intel_dpio_phy.c. The new function will also be > used in a future patch. > > Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH 6/6] drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c

This simplifies the pll enable/disable a code a bit and hides the sideband message neatly in intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 19

[Intel-gfx] [PATCH 3/6] drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart

With the bulk of the dpio code moved out of the vlv/chv prepare pll functions into intel_dpio_phy.c, those functions became simple enough that they can be merged with the pll enabling function, that always succeeds the prepare call. Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH 5/6] drm/i915: Move CHV divider readout to intel_dpio_phy.c

Reading the dividers depends on sideband messaging, so it fits well if the other functions in intel_dpio_phy.c. The new function will also be used in a future patch. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2

[Intel-gfx] [PATCH 4/6] drm/i915: Move VLV divider readout to intel_dpio_phy.c

Reading the dividers depends on sideband messaging, so it fits well if the other functions in intel_dpio_phy.c. The new function will also be used in a future patch. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2

[Intel-gfx] [PATCH 2/6] drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c

Hide the dpio details of setting up the dplls on VLV/CHV to intel_dpio_phy.c. This will allow the prepare and enable pll functions to be merged in a follow up. It also creates a better split of the code where most of the dpio access are concentrated in one place. Signed-off-by: Ander Conselvan de

[Intel-gfx] [PATCH 1/6] drm/i915: Rename struct dpll to struct intel_dpll

Prefix struct dpll with intel_ to follow the convention in the driver. Cc: Ville Syrjälä Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_ddi.c |

[Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c

Hi, This series moves all of the calls to vlv_dpio_{read,write} to intel_dpio_phy.c. I think it simplifies the surrounding code a bit. Thanks, Ander Ander Conselvan de Oliveira (6): drm/i915: Rename struct dpll to struct intel_dpll drm/i915: Move dpio code of VLV/CHV dpll enabling to

[Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

This is more robust for assignments and comparisons. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index

[Intel-gfx] [PATCH RESEND 2/2] drm/i915: don't mix bitwise and logical operations for has_snoop

Also make the code more readable. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_dma.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 547100fa3122..a8c79f6512a4

Re: [Intel-gfx] [PATCH i-g-t 1/3] tools/intel_bios_reader: abstract header information dumping

Fairly simple stuff, pushed the series to igt. BR, Jani. On Thu, 12 May 2016, Jani Nikula wrote: > Signed-off-by: Jani Nikula > --- > tools/intel_bios_reader.c | 52 > +++ > 1 file changed, 30

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev3)

== Series Details == Series: series starting with [1/2] drm: Add aux plane verification in addFB2 (rev3) URL : https://patchwork.freedesktop.org/series/4641/ State : failure == Summary == Applying: drm: Add aux plane verification in addFB2 Applying: drm/i915: Render decompression support for

[Intel-gfx] [PATCH v3 2/2] drm/i915: Render decompression support for Gen9 and above

This patch includes enabling render decompression (RC) after checking all the requirements (format, tiling, rotation etc.). TODO: 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render decompression must not be used in VTd pass-through mode 3. Program hashing select CHICKEN_MISC1

Re: [Intel-gfx] FreeBSD i915 driver update

On Thu, 12 May 2016, Scott Long wrote: > I'd like to offer a heads-up on the ongoing work in the FreeBSD project > to update to a contemporary version of the i915 driver. I inadvertently let this through the moderation while Scott had reposted as subscriber. Please ignore

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems

On Thu, May 12, 2016 at 03:28:16PM +0100, Chris Wilson wrote: > Under full-ppgtt, access to the global GTT is carefully regulated > through hardware functions (i.e. userspace cannot read and write to > arbitrary locations in the GGTT via the GPU). With this restriction in > place, we can forgo

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Lazily migrate the objects after hibernation

On Thu, May 12, 2016 at 03:28:15PM +0100, Chris Wilson wrote: > Now that we mark the object domains for having been restored from the > hibernation image, we not need to flush everything during resume and > can instead rely on the normal domain tracking to flush only when > required. The only

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix a few code checker errors

On Fri, May 13, 2016 at 03:24:32PM +0300, Imre Deak wrote: > On Thu, 2016-05-12 at 15:31 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Fix a few code checker errors > > URL   : https://patchwork.freedesktop.org/series/7071/ > > State : failure > > > > == Summary == >

Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_flip: Adjust tolerance when counting frames

On 13.05.2016 15:00, Chris Wilson wrote: On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote: basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to be aproximately equal with the estimated number. This is a false negative, one of the reasons being the

[Intel-gfx] FreeBSD i915 driver update

Hello intel-gfx, I'd like to offer a heads-up on the ongoing work in the FreeBSD project to update to a contemporary version of the i915 driver. For context, some background information on the earlier approaches we've taken to import the i915 driver in FreeBSD. In the past, developers often

Re: [Intel-gfx] FreeBSD i915 driver update

> I don't have any FreeBSD experience and I don't know what kind of team > of developers you have, but it is my educated guess that you'll have > plenty of more productive things to do than trying to maintain a > significant amount of delta with upstream while also trying to stay > up-to-date. I

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix a few code checker errors

On Thu, 2016-05-12 at 15:31 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix a few code checker errors > URL   : https://patchwork.freedesktop.org/series/7071/ > State : failure > > == Summary == > > Series 7071v1 drm/i915: Fix a few code checker errors >

Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_flip: Adjust tolerance when counting frames

On Fri, May 13, 2016 at 01:00:33PM +0100, Chris Wilson wrote: > On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote: > > basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to > > be aproximately equal with the estimated number. > > > > This is a false negative,

Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_flip: Adjust tolerance when counting frames

On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote: > basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to > be aproximately equal with the estimated number. > > This is a false negative, one of the reasons being the precision lost when > truncating a

[Intel-gfx] [PATCH i-g-t v3] tests/kms_flip: Adjust tolerance when counting frames

basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to be aproximately equal with the estimated number. This is a false negative, one of the reasons being the precision lost when truncating a fractional number. Fixed this by using floating point arithmetic. Cc: Jani Nikula

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Move get-reset-stats ioctl from intel_uncore.c to i915_gem_context.c

== Series Details == Series: series starting with [CI,1/4] drm/i915: Move get-reset-stats ioctl from intel_uncore.c to i915_gem_context.c URL : https://patchwork.freedesktop.org/series/7136/ State : failure == Summary == Series 7136v1 Series without cover letter

  1   2   >