Re: [Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"

On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote: > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > hang we need to be careful to not run into the "hanging too fast > check": That's not how it works. It restores the GPU by triggering a manual reset. -Chris

Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests

On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > support in the kernel. Except that the wait subtest forgot to do that, > > and therefore gets

[Intel-gfx] [PATCH 7/9] drm/i915: Add extra paranoia to ILK watermark calculations

Our low-level watermark calculation functions don't get called when the CRTC is disabled or the relevant plane is invisible, so they should never see a zero htotal or zero bpp. However add some checks to ensure this is true so that we don't wind up dividing by zero if we make a mistake elsewhere

[Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

Although we can do a good job of reading out hardware state, the graphics firmware may have programmed the watermarks in a creative way that doesn't match how i915 would have chosen to program them. We shouldn't trust the firmware's watermark programming, but should rather re-calculate how we

[Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

We've been chasing a regression[1] that prevented us from merging the last couple patches of the ILK-style atomic watermark series. We've finally identified the culprit --- if we fail to reconstruct the BIOS FB, our internal driver state was left in an inconsistent state which caused confusion

[Intel-gfx] [PATCH 3/5] scripts/kernel-doc: Improve Markdown results

From: Danilo Cesar Lemes de Paula Using pandoc as the Markdown engine cause some minor side effects as pandoc includes main tags for almost everything. Original Markdown support approach removes those main tags, but it caused some inconsistencies when that tag is

[Intel-gfx] [PATCH 4/5] scripts/kernel-doc: Use asciidoc instead of markdown

By popular demand. This needs some adjustment/fixups after feeding snippets to asciidoc since compared to markdown asciidown escapes xml markup and doesn't just let it through. The other noticeable change is that build times increase a lot - we need to launch the markup process per-snippet,

[Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"

Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu hang we need to be careful to not run into the "hanging too fast check": - don't restore the ban period, but instead keep it at 0. - make sure we idle the gpu fully before hanging it again (wait subtest missted that). With

Re: [Intel-gfx] [PATCH] drm/i915: Add some more bits to CURSOR_POS_MASK

On Wed, Nov 25, 2015 at 1:54 PM, Robert Fekete wrote: > On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote: >> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote: >> > On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote: >> > > The old

[Intel-gfx] [PATCH 0/5] Better markup for GPU DocBook

Hi all, As you might know the markup improvements have been discussed at kernel summit: https://lwn.net/Articles/662930/ Unfortunately it died in a bikeshed fest due to an alliance of people who think docs are useless and you should just read code and others who didn't know how to build the

[Intel-gfx] [PATCH 1/5] drm/doc: Convert to markdown

From: Danilo Cesar Lemes de Paula DRM Docbook is now Markdown ready. This means its doc is able to use markdown text on it. * Documentation/DocBook/drm.tmpl: Contains a table duplicated from drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore *

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)

On Wed, Nov 25, 2015 at 08:48:35AM -0800, Matt Roper wrote: > In addition to calculating final watermarks, let's also pre-calculate a > set of intermediate watermark values at atomic check time. These > intermediate watermarks are a combination of the watermarks for the old > state and the new

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote: > On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > > The wait-request interface still has the wait-seqno legacy of having to > > acquire the reset_counter under the mutex before calling. That is quite > > hairy and

[Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

Unfortunately the entire improved docbook project died at KS in a massive bikeshed. So we need to carry this around in drm private trees forever :( I discussed this with Dave at kernel summit and he's ok with this. I'll maintain the asciidoc support in topic/kerneldoc in the drm-intel.git tree.

[Intel-gfx] [PATCH 2/5] scripts/kernel-doc: Adding infrastructure for markdown support

From: Danilo Cesar Lemes de Paula Markdown support is given by calling an external tool, pandoc, for all highlighted text on kernel-doc. Pandoc converts Markdown text to proper Docbook tags, which will be later translated to pdf, html or other targets. This adds

Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > We've been chasing a regression[1] that prevented us from merging the last > couple patches of the ILK-style atomic watermark series. We've finally > identified the culprit --- if we fail to reconstruct the BIOS FB, our internal >

[Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests

This testcase tries to validate -EIO behaviour by disabling gpu reset support in the kernel. Except that the wait subtest forgot to do that, and therefore gets a return value of 0 instead of the expected -EIO. With this fix gem_eio passes on a kernel with my fixes completely. Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

On Wed, Nov 25, 2015 at 08:48:34AM -0800, Matt Roper wrote: > Although we can do a good job of reading out hardware state, the > graphics firmware may have programmed the watermarks in a creative way > that doesn't match how i915 would have chosen to program them. We > shouldn't trust the

Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote: > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > > We've been chasing a regression[1] that prevented us from merging the last > > couple patches of the ILK-style atomic watermark series. We've finally > > identified the

[Intel-gfx] [PATCH i-g-t v2] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

Second attempt using Imres' hints. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote: > On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: > > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: > > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote: > > > > On Tue, Nov 24, 2015 at

Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

On Wed, Nov 25, 2015 at 09:04:11AM -0800, Matt Roper wrote: > On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote: > > > We've been chasing a regression[1] that prevented us from merging the last > > > couple patches of the

Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests

On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > This testcase tries to validate -EIO behaviour by disabling gpu reset > support in the kernel. Except that the wait subtest forgot to do that, > and therefore gets a return value of 0 instead of the expected -EIO. > Wrong. It was

[Intel-gfx] [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)

Plane state objects contain two copies of src/dest coordinates: the original (requested by userspace) coordinates in the base drm_plane_state object, and a second, clipped copy (i.e., what we actually want to program to the hardware) in intel_plane_state. We've only been setting up the former

[Intel-gfx] [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state

The intel_dump_pipe_config() always dumps the currently active plane state for each plane on a CRTC. If we're calling this function to dump CRTC state that is in-flight (not yet active), then this mismatch can be misleading and confusing. Let's pay attention to whether the state we're dumping is

[Intel-gfx] [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state

When watermark calculation was moved up to the atomic check phase, the code was updated to calculate based on in-flight atomic state rather than already-committed state. However the hsw_compute_linetime_wm() didn't get updated and continued to pull values out of the currently-committed CRTC

[Intel-gfx] [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed

We dump during HW state readout, but that's too early to reflect how the primary plane is actually configured. In the future it would be nice if we could just read out HW state and reconstruct FB's at the same point, but at the moment we don't have GEM initialized sufficiently during hardware

[Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means

[Intel-gfx] [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2)

During state dumping, list planes that have an FB but are invisible (e.g., because they're offscreen or clipped by other planes) as "not visible" rather than "enabled." While we're at it, dump the FB format as a human-readable string rather than a hex format code. v2: Don't add bpp; make format

[Intel-gfx] [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb

If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best

[Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

From: Marius Vlad Signed-off-by: Marius Vlad --- tests/pm_rpm.c | 120 + 1 file changed, 120 insertions(+) diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c index c4fb19c..157cf29 100644 ---

[Intel-gfx] [PATCH 3/9] drm/nouveau: Use EAGAIN instead EBUSY for aux retry.

Current EBUSY meaning is immediately retry, but this is about to change. DRM aux transfer is about to change and make EAGAIN the immediately retry and use EBUSY to wait a bit for aux channels to recover for any error or wake up. This has no functional change if the EAGAIN support is in place

[Intel-gfx] [PATCH 2/9] drm: Introduce EAGAIN handling for immediatelly aux retries

The goal here is to offload aux retries handling from the drivers to drm. However there are 2 differents cases for retry: 1. Immediately retry - Hardware already took care of needed timeouts before answering that a retry is possible. 2. Busy - Wait some time and retry.

[Intel-gfx] [PATCH 8/9] drm/i915: Move dummy aux read from read_wake to aux_transfer.

The goal is to kill the intel_dp_dpcd_read_wake for all, however Jani noticed we cannot ignore the case introduced by: 'commit f6a1906 ("drm/i915: Do a dummy DPCD read before the actual read")' So, instead for removing this for now let's apply that dummy read to all DP_AUX_NATIVE_READ cases.

[Intel-gfx] [PATCH 7/9] drm/i915: Fix random aux transactions failures.

Mainly aux communications on sink_crc were failing a lot randomly on recent platforms. The first solution was to try to use intel_dp_dpcd_read_wake, but then it was suggested to move retries to drm level. Since drm level was already taking care of retries and didn't want to through random retries

[Intel-gfx] [PATCH 0/9] Organize aux retries v3

This new version first convert the drm_dp_aux doc to new per-member comment layout and introduce a propper documentation for EBUSY/EAGAIN retry cases, as requested by Daniel. Also accept many suggestions from Jani, but mostly removes the Nacked patch and introduce a new one to handle the missed

[Intel-gfx] [PATCH 6/9] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

EBUSY retries are already in place at drm level. We don't need to replicate the job here. v2: rebase on top of EAGAIN x EBUSY retries change at drm. EBUSY retry at DRM is now handling the msleep(1). Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c |

[Intel-gfx] [PATCH 4/9] drm/i915: Use EAGAIN instead EBUSY for aux retry.

Current EBUSY meaning is immediately retry, but this is about to change. DRM aux transfer is about to change and make EAGAIN the immediately retry and use EBUSY to wait a bit for aux channels to recover for any error or wake up. This has no functional change if the EAGAIN support is in place

[Intel-gfx] [PATCH 1/9] drm: Improve drm_dp_aux DocBook.

This patch converts drm_dp_aux doc to new per-member comment layout that 4.4 supports as suggested by Daniel. But also: 1. to let the split text with sense this patch also introduce a brief general AUX channel definition. 2. Remove .name and .dev duplications from the original text. 3. Improve

[Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

If the system has no available swap pages, we cannot make forward progress in the shrinker by releasing active pages, only by releasing purgeable pages which are immediately reaped. Take total_swap_pages into account when counting up available objects to be shrunk and subsequently shrinking them.

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote: > +static bool swap_available(void) > +{ > + return total_swap_pages || frontswap_enabled; > +} Of course these aren't exported symbols, so really this is just RFC right now. -Chris -- Chris Wilson, Intel Open Source Technology

[Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin patch in order to pin buffers to a certain VA.

[Intel-gfx] [PATCH 9/9] drm/i915: Kill intel_dp_dpcd_read_wake

This read wake with retries were initially added by 2 commits: commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure") commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times when detecting") Both mentioning section 9.1 of the 1.1a DisplayPort spec, that

[Intel-gfx] [PATCH 5/9] drm: Wait 1ms before retrying aux transactions on EBUSY.

DP Specs isn't really clear about the amount of retries, but for cases it mentions retries it also mention times that vary from 300us to 1ms. For many cases hardware can handled the timeouts before retry is possible and allowed, but for many other cases it is better to wait and give time so the

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On 11/25/2015 10:58 PM, Chris Wilson wrote: On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote: On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä

[Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio

My apologies to Chris Wilson for being dense on this topic for essentially for years. This patch doesn't do any big redesign of the overall reset flow, but instead just applies changes where it's needed to obey gem_eio. We can redesign later on, but for now I prefer to make the testcase happy

[Intel-gfx] [PATCH v2] drm/i915/guc: Clean up locks in GuC

From: Alex Dai When GuC Work Queue is full, driver will wait GuC for avaliable space by delaying 1ms. The wait needs to be out of spinlockirq / unlock. Otherwise, lockup happens because jiffies won't be updated dur to irq is disabled. The unnecessary locks has been cleared.

Re: [Intel-gfx] [PATCH v3] drm/i915: Eliminate vmap overhead for cmd parser

On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote: > With a little complexity to handle cmds straddling page boundaries, we > can completely avoiding having to vmap the batch and the shadow batch > objects whilst running the command parser. > > On ivb i7-3720MQ: > > x11perf -dot

Re: [Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio

On Wed, Nov 25, 2015 at 06:45:26PM +0100, Daniel Vetter wrote: > My apologies to Chris Wilson for being dense on this topic for > essentially for years. > > This patch doesn't do any big redesign of the overall reset flow, but > instead just applies changes where it's needed to obey gem_eio. We

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote: > If the system has no available swap pages, we cannot make forward > progress in the shrinker by releasing active pages, only by releasing > purgeable pages which are immediately reaped. Take total_swap_pages into > account when

Re: [Intel-gfx] [PATCH v3] drm/i915: Eliminate vmap overhead for cmd parser

On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote: > On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote: > > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs > > *ring, > > } > > > > #define LENGTH_BIAS 2 > > +#define MAX_PARTIAL 256 > > There

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote: > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote: > > If the system has no available swap pages, we cannot make forward > > progress in the shrinker by releasing active pages, only by releasing > > purgeable pages which

Re: [Intel-gfx] [PATCH v3] drm/i915: Eliminate vmap overhead for cmd parser

On Wed, Nov 25, 2015 at 08:13:43PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote: > > > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs > > > *ring, > > > } > >

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

On 11/25/2015 07:02 AM, Mika Kuoppala wrote: Nick Hoath writes: > Use the first retired request on a new context to unpin > the old context. This ensures that the hw context remains > bound until it has been written back to by the GPU. > Now that the context is

Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

On ke, 2015-11-25 at 19:16 +0200, marius.c.v...@intel.com wrote: > From: Marius Vlad > > Signed-off-by: Marius Vlad > --- >  tests/pm_rpm.c | 120 > + >  1 file changed, 120 insertions(+) >

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

On Wed, Nov 25, 2015 at 08:31:02PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote: > > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote: > > > +static bool swap_available(void) > > > +{ > > > + return total_swap_pages || frontswap_enabled;

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

OK, here is my understanding. We do context pin/unpin during create/free request or during submit/retire request but with condition (dirty) check. So the context pincount will be # of requests plus 1, if it is dirty. Dirty means that context likely is accessed by HW, while not-dirty means HW

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

On Thu, 26 Nov 2015 07:06:56 +0100, Zhang, Xiong Y wrote: > > > On Wed, 25 Nov 2015 11:57:13 +0100, > > Zhang, Xiong Y wrote: > > > > > > > On Wed, 25 Nov 2015 10:56:51 +0100, > > > > Zhang, Xiong Y wrote: > > > > > > > > > > Recently I always see the following error message during S4 or S3 > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly

On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote: > We had the "The master control interrupt lied (SDE)!" check and error > message in place for a long time without any problems, until > > commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e > Author: Sonika Jindal

Re: [Intel-gfx] [PATCH] drm/i915: Don't compare has_drrs strictly in pipe config

On Wed, Nov 25, 2015 at 03:26:47PM +0100, Takashi Iwai wrote: > The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in > pipe_config_compare, v2] relaxed the way to compare the pipe > configurations, but one new comparison sneaked in there: it added the > strict has_drrs value check. This

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

Nick Hoath writes: > Use the first retired request on a new context to unpin > the old context. This ensures that the hw context remains > bound until it has been written back to by the GPU. > Now that the context is pinned until later in the request/context >

[Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

From: Ville Syrjälä LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns for transocoder B/C. And more importnatnly we should not consider the state of underrun reporting for transcoders B/C when checking whether we can enable the south error

Re: [Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

On Wed, Nov 25, 2015 at 05:11:23PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns > for transocoder B/C. And more importnatnly we should not consider > the state of

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Remove double wait_for_vblank on broadwell.

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > wait_vblank is already set in intel_plane_atomic_calc_changes > for broadwell, waiting for a double vblank is overkill. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote: > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote: > > > Instead of querying the reset counter before every access to the ring, > > > query it the first

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Calculate watermark related members in the crtc_state, v3.

On Tue, 2015-11-24 at 15:55 +0100, Maarten Lankhorst wrote: > Op 24-11-15 om 15:03 schreef Ander Conselvan De Oliveira: > > On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > > > This removes pre/post_wm_update from intel_crtc->atomic, and > > > creates atomic state for it in

Re: [Intel-gfx] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros

On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote: > > On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote: > > > /* Iterate over initialised rings */ > > > #define for_each_ring(ring__, dev_priv__, i__) \ > > >

Re: [Intel-gfx] [PATCH 03/12] drm/i915/skl: Update watermarks before the crtc is disabled.

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > On skylake some of the registers are only writable when the correct > power wells are enabled. Because of this watermarks have to be updated > before the crtc turns off, or you get unclaimed register read and write > warnings. > > This

[Intel-gfx] [PATCH] drm/i915: Ditch drm_can_sleep check in wait_for

It's causing endless amounts of trouble by hiding pretty serious bugs where we wait for a few msecs, but accidentally while holding a spinlock (sometimes even an irqsafe one). And the only reason for this was to make the mode for the panic handler work somewhat. But that _really_ needs to be done

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix potential dangling else problems in for_each_ macros

On Tue, Nov 24, 2015 at 09:21:56PM +0200, Jani Nikula wrote: > We have serious dangling else bugs waiting to happen in our for_each_ > style macros with ifs. Consider, for example, > > #define for_each_power_domain(domain, mask) \ > for ((domain) = 0; (domain) <

[Intel-gfx] [i-g-t PATCH] scripts: remove display_debug.sh as obsolete

The script uses the obsoleted and removed intel_reg_read tool. Rather than mechanically fix this to use intel_reg, observe that the hardcoded register offsets are platform specific. A quick glance suggests they are for PCH split platforms with FDI, and as such useful only on a minority of

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote: > Hm it's not just batches but any object with relocs. Could this explain > the oddball libva/uxa hang? Stuff like "after playing $game for hours my > desktop looked funny", but not for tiling issues. Possible, but with libva having

Re: [Intel-gfx] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros

On Wed, 25 Nov 2015, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote: >> On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote: >> > /* Iterate over initialised rings */ >> > #define for_each_ring(ring__, dev_priv__, i__) \ >> >

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote: > > > On 11/25/2015 2:51 PM, Daniel Vetter wrote: > >On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: > >>On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: > >>>On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville

Re: [Intel-gfx] intel_dp_detect redesign

On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote: > Hi Ander, > > Dave had a short discussion about reprobing DP (and MST) state on > resume. I think this is something we've missed in our dp hpd handling > rework thus far. And at least for SST we need to take it into account > since

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

On Wed, 25 Nov 2015 10:56:51 +0100, Zhang, Xiong Y wrote: > > Recently I always see the following error message during S4 or S3 resume with > drm-intel-nightly. > [ 97.778063] PM: Syncing filesystems ... done. > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done. > [

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Rename request->ringbuf to request->ring

On 24/11/15 15:25, Chris Wilson wrote: On Tue, Nov 24, 2015 at 03:08:09PM +, Tvrtko Ursulin wrote: On 20/11/15 12:43, Chris Wilson wrote: Now that we have disambuigated ring and engine, we can use the clearer and more consistent name for the intel_ringbuffer pointer in the request.

Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote: > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote: > > > If the system has no available swap pages, we cannot make forward > > > progress in the shrinker by

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote: > > > > From: Akash Goel

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On 11/25/2015 2:51 PM, Daniel Vetter wrote: On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote: On Tue, Nov 24, 2015 at 03:35:24PM +0530,

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

Recently I always see the following error message during S4 or S3 resume with drm-intel-nightly. [ 97.778063] PM: Syncing filesystems ... done. [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff] [

Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote: > On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote: > > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote: > > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote: > > > > If the system has no

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

On Wed, Nov 25, 2015 at 09:02:20AM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote: > > Hm it's not just batches but any object with relocs. Could this explain > > the oddball libva/uxa hang? Stuff like "after playing $game for hours my > > desktop looked

Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired

On 24/11/15 17:47, Daniel Vetter wrote: On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Current code moves _any_ VMA to the inactive list only when _all_ rendering on an object (so from any context or VM) has been completed.

Re: [Intel-gfx] [PATCH 0/4] PSR general improvements and stabilization.

On Tue, Nov 24, 2015 at 08:53:43PM +, Vivi, Rodrigo wrote: > On Tue, 2015-11-24 at 17:12 +, Daniel Stone wrote: > > Hi Rodrigo, > > > > On 11 November 2015 at 21:19, Rodrigo Vivi > > wrote: > > > Proceeding with the big series split here goes the general PSR > >

[Intel-gfx] [i-g-t PATCH] tools: fix intel_gpu_abrt to use intel_reg

intel_reg_dumper is gone, replaced by 'intel_reg dump'. Signed-off-by: Jani Nikula --- tools/intel_gpu_abrt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt index a38137d795f4..bde6fb0d2493 100755 ---

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

On Tue, Nov 24, 2015 at 02:34:46PM -0800, Yu Dai wrote: > > > On 11/24/2015 11:13 AM, Daniel Vetter wrote: > >On Tue, Nov 24, 2015 at 10:36:54AM -0800, Yu Dai wrote: > >> > >> > >> On 11/24/2015 10:08 AM, Daniel Vetter wrote: > >> >On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote: > >>

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

On Tue, Nov 24, 2015 at 11:01:25PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 07:06:21PM +0100, Daniel Vetter wrote: > > Just setting obj->dirty only works if you also have the pages. > > Exactly. The CPU access has historically always been page-by-page. The > style here more or less to

Re: [Intel-gfx] [PATCH 01/29] pci: Decouple quirks.c from i915_reg.h

Hi Ville, On Wed, Nov 04, 2015 at 11:19:49PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > i915 register defines are going to become type safe, so going forward > the register defines can't be used as straight numbers. Since quirks.c >

[Intel-gfx] [iGVT-g] XenGT for PV guest

Hi all, I am trying to enable XenGT for Android on board vtc1010 in PV mode. Used: - Intel® Atom™ processor E3827 - Xen 4.3.1 on branch "byt_experiment". - dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version - domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs) kernel version

[Intel-gfx] [i-g-t PATCH] tests: fix ddx_intel_after_fbdev to use intel_reg

intel_reg_dumper is gone, replaced by 'intel_reg dump'. Signed-off-by: Jani Nikula --- tests/ddx_intel_after_fbdev | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev index

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

> On Wed, 25 Nov 2015 10:56:51 +0100, > Zhang, Xiong Y wrote: > > > > Recently I always see the following error message during S4 or S3 resume > with drm-intel-nightly. > > [ 97.778063] PM: Syncing filesystems ... done. > > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds)

[Intel-gfx] [PATCH] drm/i915: Disable FLT if DP config changes

Disable DP fast link training if DP link configuration changes. If one of the DP link parameters i.e. link bandwidth, lane count, rate selection, port clock or bpp changes the link training does no longer apply the previously computed voltage swing and pre-emphasis values. Instead, the link

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote: > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote: > > > > From: Akash Goel

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

On Wed, 25 Nov 2015 11:57:13 +0100, Zhang, Xiong Y wrote: > > > On Wed, 25 Nov 2015 10:56:51 +0100, > > Zhang, Xiong Y wrote: > > > > > > Recently I always see the following error message during S4 or S3 resume > > with drm-intel-nightly. > > > [ 97.778063] PM: Syncing filesystems ... done. > >

[Intel-gfx] [PATCH i-g-t] scripts: Add feature list file for piglit 'summary feature'

This is a placeholder for the feature list file. Its content is just an example. This needs to be filled in by feature owners with the feature name and the corresponding tests regex. Please refer to this piglit commit for more info on this feature. commit

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote: > On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote: > > > > Instead of querying the

Re: [Intel-gfx] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT

On Mon, 16 Nov 2015, Deepak M wrote: > For dual link panel scenarios there are new fileds added in the > VBT which indicate on which port the PWM cntrl and CABC ON/OFF > commands needs to be sent. > > Cc: Jani Nikula > Cc: Daniel Vetter

Re: [Intel-gfx] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT

On Wed, 25 Nov 2015, Jani Nikula wrote: > On Mon, 16 Nov 2015, Deepak M wrote: >> For dual link panel scenarios there are new fileds added in the >> VBT which indicate on which port the PWM cntrl and CABC ON/OFF >> commands needs to be sent. >> >> Cc:

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating a

  1   2   >