Re: [Intel-gfx] [PATCH 14/19] drm/i915: Reduce locking inside swfinish ioctl

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > We only need to take the struct_mutex if the object is pinned to the > display engine and so requires checking for clflush. (The race with > userspace pinning the object to a framebuffer is irrelevant.) > > v2: Use access once for compiler hi

Re: [Intel-gfx] [PATCH 06/19] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

On Fri, Aug 05, 2016 at 09:16:21AM +0300, Joonas Lahtinen wrote: > On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > > @@ -486,7 +486,8 @@ void __i915_add_request(struct drm_i915_gem_request > > *request, > >    */ > >   request->emitted_jiffies = jiffies; > >   request->previous_seqno

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Document and reject invalid tiling modes

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > Through the GTT interface to the fence registers, we can only handle > linear, X and Y tiling. The more esoteric tiling patterns are ignored. > Document that the tiling ABI only supports upto Y tiling, and reject any > attempts to set a tiling

Re: [Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

On Tue, Aug 02, 2016 at 03:37:27PM +0300, Jani Nikula wrote: > On Tue, 02 Aug 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The spec was recently fixed to have the correct iboost setting for the > > SKL Y/U DP DDI buffer translation table entry 2. Update our tables > >

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

> -Original Message- > From: Pandiyan, Dhinakaran > Sent: Friday, August 5, 2016 2:42 PM > To: Yang, Libin > Cc: intel-gfx@lists.freedesktop.org; ti...@suse.de; alsa-devel@alsa- > project.org; libin.y...@linux.intel.com > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Fri, 2016-08-05 at 06:21 +, Yang, Libin wrote: > > -Original Message- > > From: Pandiyan, Dhinakaran > > Sent: Friday, August 5, 2016 1:57 PM > > To: Yang, Libin > > Cc: intel-gfx@lists.freedesktop.org; ti...@suse.de; alsa-devel@alsa- > > project.org; libin.y...@linux.intel.com > >

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, August 5, 2016 2:36 PM > To: Yang, Libin > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; > jani.nik...@linux.intel.com; Vetter, Daniel ; > ti...@suse.de > Subject: Re: [PA

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

On Fri, Aug 05, 2016 at 06:16:59AM +, Yang, Libin wrote: > Hi Ville, > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Friday, August 5, 2016 1:57 PM > > To: Yang, Libin > > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Minor clean up related to link training function declarations

== Series Details == Series: drm/i915: Minor clean up related to link training function declarations URL : https://patchwork.freedesktop.org/series/10689/ State : failure == Summary == Series 10689v1 drm/i915: Minor clean up related to link training function declarations http://patchwork.free

Re: [Intel-gfx] [PATCH 08/19] drm/i915/shrinker: Wait before acquiring struct_mutex under oom

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > We can now wait for the GPU (all engines) to become idle without > requiring the struct_mutex. Inside the shrinker, we need to currently > take the struct_mutex in order to purge objects and to purge the objects > we need the GPU to be idle -

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

> -Original Message- > From: Pandiyan, Dhinakaran > Sent: Friday, August 5, 2016 1:57 PM > To: Yang, Libin > Cc: intel-gfx@lists.freedesktop.org; ti...@suse.de; alsa-devel@alsa- > project.org; libin.y...@linux.intel.com > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes

Re: [Intel-gfx] [PATCH 07/19] drm/i915: Simplify do_idling() (Ironlake vt-d w/a)

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > Now that we pass along the expected interruptible nature for the > wait-for-idle, we do not need to modify the global > i915->mm.interruptible for this single call. (Only the immediate call to > i915_gem_wait_for_idle() takes the interruptible

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

Hi Ville, > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, August 5, 2016 1:57 PM > To: Yang, Libin > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; > jani.nik...@linux.intel.com; Vetter, Daniel ; > ti...@suse.de > Subject

Re: [Intel-gfx] [PATCH 06/19] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > -i915_gem_suspend(struct drm_device *dev) > +int i915_gem_suspend(struct drm_device *dev) >  { >   struct drm_i915_private *dev_priv = to_i915(dev); > - int ret = 0; > + int ret; >   >   intel_suspend_gt_powersave(dev_priv); >

[Intel-gfx] ✗ Ro.CI.BAT: failure for Improve logging for DP link training (rev2)

== Series Details == Series: Improve logging for DP link training (rev2) URL : https://patchwork.freedesktop.org/series/10637/ State : failure == Summary == Series 10637v2 Improve logging for DP link training http://patchwork.freedesktop.org/api/1.0/series/10637/revisions/2/mbox Test drv_modu

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Fri, 2016-08-05 at 02:35 +, Yang, Libin wrote: > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of > > Dhinakaran Pandiyan > > Sent: Wednesday, August 3, 2016 10:15 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: alsa-de...

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

On Fri, Aug 05, 2016 at 05:39:19AM +, Yang, Libin wrote: > Hi Ville, > > Sorry for delay reply. Please see my comments below. > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Thursday, August 4, 2016 4:53 PM > > To: libin.y...@linux.int

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/19] drm/i915: Introduce i915_gem_active_wait_unlocked()

== Series Details == Series: series starting with [01/19] drm/i915: Introduce i915_gem_active_wait_unlocked() URL : https://patchwork.freedesktop.org/series/10686/ State : failure == Summary == Series 10686v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/10686/re

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Remove forced stop ring on suspend/unload

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > Before suspending (or unloading), we would first wait upon all rendering > to be completed and then disable the rings. This later step is a remanent > from DRI1 days when we did not use request tracking for all operations > upon the ring. Now

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: set proper N/MCTS on more platforms

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, August 4, 2016 4:54 PM > To: libin.y...@linux.intel.com > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, > Daniel > ; ti...@suse.de; Yang, Libin > Subject: Re: [

Re: [Intel-gfx] [PATCH 02/19] drm/i915: Convert non-blocking waits for requests over to using RCU

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote: > We can completely avoid taking the struct_mutex around the non-blocking > waits by switching over to the RCU request management (trading the mutex > for a RCU read lock and some complex atomic operations). The improvement > is that we gain fur

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

Hi Ville, Sorry for delay reply. Please see my comments below. > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, August 4, 2016 4:53 PM > To: libin.y...@linux.intel.com > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Ve

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: Bring MIPI out of reset

== Series Details == Series: drm/i915/bxt: Bring MIPI out of reset URL : https://patchwork.freedesktop.org/series/10682/ State : failure == Summary == Applying: drm/i915/bxt: Bring MIPI out of reset fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h). error: could n

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

Regards Shashank On 8/4/2016 9:39 PM, Daniel Vetter wrote: On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote: On 4 August 2016 at 14:15, Sharma, Shashank wrote: On 8/4/2016 5:04 PM, Emil Velikov wrote: On 4 August 2016 at 11:16, Sharma, Shashank wrote: Hello Emil, Thanks for

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Dhinakaran Pandiyan > Sent: Wednesday, August 3, 2016 10:15 AM > To: intel-gfx@lists.freedesktop.org > Cc: alsa-de...@alsa-project.org; ti...@suse.de; libin.y...@linux.intel.com; > Pandiy

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Ville Syrjälä > Sent: Friday, August 5, 2016 4:48 AM > To: Takashi Iwai > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; alsa- > de...@alsa-project.org; Pandiyan, Dhina

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > Reviewed-by: Lyude Merged to dinq. Thanks for the quick review. Matt > > On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote: > > The bspec was updated a couple weeks ago to add an extra block per > > line > > to plane watermark calcul

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix enc_to_dig_port for MST encoders

There was some discussion that happened on the original version of this patch: https://patchwork.kernel.org/patch/8960831/ The general consensus was while this fixed the issue, it probably isn't the way we want to fix it. It would be a better idea just to have enc_to_mst_primary() or something al

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move audio_connector to intel_encoder

Reviewed-by: Lyude On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote: > With DP MST, a digital_port can carry more than one audio stream. > Hence, > more than one audio_connector needs to be attached to > intel_digital_port in > such cases. However, each stream is associated with an un

Re: [Intel-gfx] [PATCH 1/3] drm/i915: start adding dp mst audio

This should be added after patch #3, since that's the one that fixes enc_to_mst(). Otherwise: Reviewed-by: Lyude On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote: > From: Libin Yang > > (This patch is developed by Dave Airlie > originally) > > This patch adds support for DP MST a

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Reviewed-by: Lyude On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote: > The bspec was updated a couple weeks ago to add an extra block per > line > to plane watermark calculations for linear pixel formats. > > Bspec update 115327 description: >   "Gen9+ - Updated the plane blocks per line calc

[Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

The bspec was updated a couple weeks ago to add an extra block per line to plane watermark calculations for linear pixel formats. Bspec update 115327 description: "Gen9+ - Updated the plane blocks per line calculation for linear cases. Adds +1 for all linear cases to handle the non-block align

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

[dropped stable ML and add a few other relevant people to Cc] On Thu, 04 Aug 2016 20:05:27 +0200, Takashi Iwai wrote: > > On Thu, 04 Aug 2016 18:44:11 +0200, > Daniel Vetter wrote: > > > > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > > > On Haswell/Broadwell, the HD-Audio bloc

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Thu, Aug 04, 2016 at 07:55:09PM +0200, Takashi Iwai wrote: > On Thu, 04 Aug 2016 19:35:16 +0200, > Ville Syrjälä wrote: > > > > On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote: > > > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote: > > > > On Tue, Aug 02, 2016 at 07:14:3

Re: [Intel-gfx] [PATCH i-g-t] igt_kms: Use proper panning coordinates for legacy primary plane updates

On Wed, Aug 03, 2016 at 10:35:15AM -0700, Bob Paauwe wrote: > On Wed, 3 Aug 2016 09:15:41 -0700 > Matt Roper wrote: > > > A copy/paste error resulted in us using src_x for both the x and y > > panning coordinates; make sure we use src_y instead for the appropriate > > parameter. > > > > Fixes: 0

[Intel-gfx] [PATCH] drm/i915: Minor clean up related to link training function declarations

No functional change. Organizing the declarations for functions implemented in intel_dp_link_training.c Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_drv.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu

[Intel-gfx] [PATCH v2 0/2] Improve logging for DP link training

We do not currently output enough information to help debugging DP link training issues. For e.g., training pattern and link status information. This series aims to correct that by adding debug messages that can help developers. v2: Rebased. Removed patches that are unrelated and/or ne

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Dump DP link status when link training stages fail

A full dump of link status can be handy in debugging link training failures. Let's add that to the debug messages when link training fails. v2: Removing unrelated clean up (Jani) Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++ 1 file changed

[Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Add debug messages to print DP link training pattern

Currently we do not print the training pattern used in any of the DP link training stages. Including this piece of information in debug messages will help debugging. Also, use the wrapper intel_dp_program_link_training_pattern() in intel_dp_enable_port() instead of implementing it. v2: Downgraded

[Intel-gfx] [PATCH 10/19] drm/i915: Remove unused no-shrinker-steal

After removing the user of this wart, we can remove the wart entirely. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem_shrinker.c | 3 --- 2 files changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 08/19] drm/i915/shrinker: Wait before acquiring struct_mutex under oom

We can now wait for the GPU (all engines) to become idle without requiring the struct_mutex. Inside the shrinker, we need to currently take the struct_mutex in order to purge objects and to purge the objects we need the GPU to be idle - causing a stall whilst we hold the struct_mutex. We can hide m

[Intel-gfx] [PATCH 06/19] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

The principal motivation for this was to try and eliminate the struct_mutex from i915_gem_suspend - but we still need to hold the mutex current for the i915_gem_context_lost(). (The issue there is that there may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and struct_mutex via th

[Intel-gfx] [PATCH 04/19] drm/i915/userptr: Remove superfluous interruptible=false on waiting

Inside the kthread context, we can't be interrupted by signals so touching the mm.interruptible flag is pointless and wait-request now consumes EIO itself. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_userptr.c | 9 + 1 file changed, 1 inser

[Intel-gfx] [PATCH 09/19] drm/i915: Tidy generation of the GTT mmap offset

If we make the observation that mmap-offsets are only released when we free an object, we can then deduce that the shrinker only creates free space in the mmap arena indirectly by flushing the request list and freeing expired objects. If we combine this with the lockless vma-manager and lockless id

[Intel-gfx] [PATCH 07/19] drm/i915: Simplify do_idling() (Ironlake vt-d w/a)

Now that we pass along the expected interruptible nature for the wait-for-idle, we do not need to modify the global i915->mm.interruptible for this single call. (Only the immediate call to i915_gem_wait_for_idle() takes the interruptible status as the other action, dma_map_sg(), is independent of i

[Intel-gfx] [PATCH 12/19] drm/i915: Remove (struct_mutex) locking for wait-ioctl

With a bit of care (and leniency) we can iterate over the object and wait for previous rendering to complete with judicial use of atomic reference counting. The ABI requires us to ensure that an active object is eventually flushed (like the busy-ioctl) which is guaranteed by our management of reque

[Intel-gfx] [PATCH 11/19] drm/i915: Do a nonblocking wait first in pread/pwrite

If we try and read or write to an active request, we first must wait upon the GPU completing that request. Let's do that without holding the mutex (and so allow someone else to access the GPU whilst we wait). Upn completion, we will reacquire the mutex and only then start the operation (i.e. we do

[Intel-gfx] [PATCH 13/19] drm/i915: Remove (struct_mutex) locking for busy-ioctl

By applying the same logic as for wait-ioctl, we can query whether a request has completed without holding struct_mutex. The biggest impact system-wide is removing the flush_active and the contention that causes. Testcase: igt/gem_busy Signed-off-by: Chris Wilson Cc: Akash Goel --- drivers/gpu/

[Intel-gfx] [PATCH 19/19] drm/i915: Assert that the request hasn't been retired

With all callers now not playing tricks with dropping the struct_mutex between waiting and retiring, we can assert that the request is ready to be retired. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_request.c | 6 ++ 1 file changed, 2 insertio

[Intel-gfx] [PATCH 17/19] drm/i915: Document and reject invalid tiling modes

Through the GTT interface to the fence registers, we can only handle linear, X and Y tiling. The more esoteric tiling patterns are ignored. Document that the tiling ABI only supports upto Y tiling, and reject any attempts to set a tiling mode other than NONE, X or Y. Signed-off-by: Chris Wilson C

[Intel-gfx] [PATCH 18/19] drm/i915: Repack fence tiling mode and stride into a single integer

In the previous commit, we moved the obj->tiling_mode out of a bitfield and into its own integer so that we could safely use READ_ONCE(). Let us now repair some of that damage by sharing the tiling_mode with its companion, the fence stride. v2: New magic Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH 15/19] drm/i915: Remove pinned check from madvise ioctl

We don't need to incur the overhead of checking whether the object is pinned prior to changing its madvise. If the object is pinned, the madvise will not take effect until it is unpinned and so we cannot free the pages being pointed at by hardware. Marking a pinned object with allocated pages as DO

[Intel-gfx] [PATCH 16/19] drm/i915: Remove locking for get_tiling

Since we are not concerned with userspace racing itself with set-tiling (the order is indeterminant even if we take a lock), then we can safely read back the single obj->tiling_mode and do the static lookup of swizzle mode without having to take a lock. get-tiling is reasonably frequent due to the

[Intel-gfx] [PATCH 14/19] drm/i915: Reduce locking inside swfinish ioctl

We only need to take the struct_mutex if the object is pinned to the display engine and so requires checking for clflush. (The race with userspace pinning the object to a framebuffer is irrelevant.) v2: Use access once for compiler hints (or not as it is a bitfield) v3: READ_ONCE, obj->pin_display

[Intel-gfx] [PATCH 03/19] drm/i915: Convert non-blocking userptr waits for requests over to using RCU

We can completely avoid taking the struct_mutex around the non-blocking waits by switching over to the RCU request management (trading the mutex for a RCU read lock and some complex atomic operations). The improvement is that we gain further contention reduction, and overall the code become simpler

[Intel-gfx] [PATCH 05/19] drm/i915: Remove forced stop ring on suspend/unload

Before suspending (or unloading), we would first wait upon all rendering to be completed and then disable the rings. This later step is a remanent from DRI1 days when we did not use request tracking for all operations upon the ring. Now that we are sure we are waiting upon the very last operation b

[Intel-gfx] Using RCU requests, take 2

Joonas has gone through this series once and now hopefully this captures his feedback. Join in, have fun! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/19] drm/i915: Convert non-blocking waits for requests over to using RCU

We can completely avoid taking the struct_mutex around the non-blocking waits by switching over to the RCU request management (trading the mutex for a RCU read lock and some complex atomic operations). The improvement is that we gain further contention reduction, and overall the code become simpler

[Intel-gfx] [PATCH 01/19] drm/i915: Introduce i915_gem_active_wait_unlocked()

It is useful to be able to wait on pending rendering without grabbing the struct_mutex. We can do this by using the i915_gem_active_get_rcu() primitive to acquire a reference to the pending request without requiring struct_mutex, just the RCU read lock, and then call i915_wait_request(). v2: Rebas

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

On Wed, Aug 03, 2016 at 03:48:02PM +, Vivi, Rodrigo wrote: > On Wed, 2016-08-03 at 17:26 +0200, Daniel Vetter wrote: > > On Wed, Aug 3, 2016 at 5:12 PM, Vivi, Rodrigo > > wrote: > > > > > > > > > But we know that 1.23 is bad and cause issues regardless the kernel > > > version. And please ke

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

On Tue, Aug 02, 2016 at 04:09:49PM +0200, Daniel Vetter wrote: > On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote: > > Reviewed-by: Sagar Arun Kamble > > > > You're mailer wreaks havoc with your reviewed-by tags. Pleas fix this. > > > > On 6/27/20

[Intel-gfx] [PATCH] drm/i915/bxt: Bring MIPI out of reset

and power up the DSI regulator when initializing a MIPI display. Signed-off-by: Bob Paauwe --- drivers/gpu/drm/i915/i915_reg.h | 8 drivers/gpu/drm/i915/intel_dsi.c | 13 + 2 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i9

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

On Thu, 04 Aug 2016 18:44:11 +0200, Daniel Vetter wrote: > > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > > power well and so the sna-hda audio codec acquires the display power > > well while it is operation

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Thu, 04 Aug 2016 19:35:16 +0200, Ville Syrjälä wrote: > > On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote: > > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote: > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote: > > > > DP MST provides the capabili

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote: > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote: > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote: > > > DP MST provides the capability to send multiple video and audio streams > > > via > > > one sin

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote: > > DP MST provides the capability to send multiple video and audio streams via > > one single port. This requires the API's between i915 and audio drivers to > > di

Re: [Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

On Thu, Aug 04, 2016 at 04:50:35PM +, Pandiyan, Dhinakaran wrote: > On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote: > > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote: > > > The causes of clock recovery and channel equalization failures are not > > > explicitly print

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Paper over locking inversion after registration rework (rev2)

== Series Details == Series: drm: Paper over locking inversion after registration rework (rev2) URL : https://patchwork.freedesktop.org/series/10653/ State : failure == Summary == Series 10653v2 drm: Paper over locking inversion after registration rework http://patchwork.freedesktop.org/api/1.

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

On Thu, Aug 04, 2016 at 07:44:14PM +0300, Ville Syrjälä wrote: > On Thu, Aug 04, 2016 at 06:31:21PM +0200, Daniel Vetter wrote: > > On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote: > > > It appears our calculation for the address of stolen memory is incorrect > > > for 865G, so for the

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: Add debug messages to print DP link training pattern

On Thu, 2016-08-04 at 04:07 +0100, Chris Wilson wrote: > On Wed, Aug 03, 2016 at 08:07:38PM -0700, Dhinakaran Pandiyan wrote: > > @@ -2588,7 +2592,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp, > > *DP |= DP_LINK_TRAIN_PAT_2_CPT; > > break; > >

Re: [Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote: > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote: > > The causes of clock recovery and channel equalization failures are not > > explicitly printed in debug messages. Help debugging link training > > failures by printing wh

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Dump DP link status when link training stages fails

On Thu, 2016-08-04 at 10:46 +0300, Jani Nikula wrote: > On Thu, 04 Aug 2016, Dhinakaran Pandiyan > wrote: > > A full dump of link status can be handy in debugging link training > > failures. Let's add that to the debug messages when link training fails. > > > > Signed-off-by: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

On Thu, 2016-08-04 at 15:49 +0300, Ville Syrjälä wrote: > On Wed, Aug 03, 2016 at 09:42:53PM +, Pandiyan, Dhinakaran wrote: > > On Wed, 2016-08-03 at 23:28 +0300, Ville Syrjälä wrote: > > > On Wed, Aug 03, 2016 at 07:43:06PM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2016-08-03 at 22:08

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > power well and so the sna-hda audio codec acquires the display power > well while it is operational. However, Skylake separates the powerwells > again, but yet we st

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

On Thu, Aug 04, 2016 at 06:31:21PM +0200, Daniel Vetter wrote: > On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote: > > It appears our calculation for the address of stolen memory is incorrect > > for 865G, so for the time being disable our use of that memory. > > > > Bugzilla: https://

Re: [Intel-gfx] [PATCH v2] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

On Thu, Aug 04, 2016 at 09:31:20AM +0300, Jani Nikula wrote: > On Wed, 03 Aug 2016, Chris Wilson wrote: > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled > > > > "Display flickering may occur when both FBC (Frame Buffer Compression) > > and VT - d (Intel® Virtualizat

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Update MOCS tests

On Thu, Aug 04, 2016 at 01:54:10PM -, Patchwork wrote: > == Series Details == > > Series: Update MOCS tests > URL : https://patchwork.freedesktop.org/series/10665/ > State : failure > > == Summary == > > Applying: igt/gem_mocs_settings: Remove direct register tests > fatal: sha1 informatio

[Intel-gfx] [PATCH] drm: Paper over locking inversion after registration rework

drm_connector_register_all requires a few too many locks because our connector_list locking is busted. Add another FIXME+hack to work around this. This should address the below lockdep splat: == [ INFO: possible circular locking dependency detect

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote: > It appears our calculation for the address of stolen memory is incorrect > for 865G, so for the time being disable our use of that memory. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473 > Fixes: 0ad98c74e093 ("drm/i9

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote: > On 4 August 2016 at 14:15, Sharma, Shashank wrote: > > On 8/4/2016 5:04 PM, Emil Velikov wrote: > >> > >> On 4 August 2016 at 11:16, Sharma, Shashank > >> wrote: > >>> > >>> Hello Emil, > >>> > >>> Thanks for your time. > >>> > >>> I

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/26] drm/i915: Combine loops within i915_gem_evict_something

On Thu, Aug 04, 2016 at 04:11:24PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,01/26] drm/i915: Combine loops within > i915_gem_evict_something > URL : https://patchwork.freedesktop.org/series/10676/ > State : failure > > == Summary == > > Series 10676v

Re: [Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

On Tue, Aug 02, 2016 at 03:21:57PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The spec was recently fixed to have the correct iboost setting for the > SKL Y/U DP DDI buffer translation table entry 2. Update our tables > to match. > > Cc: David Weinehall > Signed-off-b

Re: [Intel-gfx] [PATCH] drm: Paper over locking inversion after registration rework

On Thu, Aug 04, 2016 at 12:15:14PM +0200, Daniel Vetter wrote: > drm_connector_register_all requires a few too many locks because our > connector_list locking is busted. Add another FIXME+hack to work > around this. This should address the below lockdep splat: > > Cc: Imre Deak > Cc: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/26] drm/i915: Combine loops within i915_gem_evict_something

== Series Details == Series: series starting with [CI,01/26] drm/i915: Combine loops within i915_gem_evict_something URL : https://patchwork.freedesktop.org/series/10676/ State : failure == Summary == Series 10676v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/1

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

On Thu, Aug 04, 2016 at 06:35:52PM +0530, Sharma, Shashank wrote: > Thanks Daniel. > > My comments, inline. > > Regards > Shashank > On 8/4/2016 4:06 PM, Daniel Vetter wrote: > > On Thu, Aug 04, 2016 at 03:46:09PM +0530, Sharma, Shashank wrote: > > > Hello Emil, > > > > > > Thanks for your time.

Re: [Intel-gfx] [I-G-T v3 2/2] igt/gem_mocs_settings: adding RC6 tests

On Thu, Aug 04, 2016 at 02:39:26PM +0100, Peter Antoine wrote: > This change adds a RC6 test for the MOCS. The MOCS registers are loaded > and saved as part of the RC6 cycle but not all the registers are > saved/restored. This tests that those registers are correctly restored. > > Signed-off-by: P

[Intel-gfx] [CI 05/26] drm/i915: Remove i915_gem_execbuffer_retire_commands()

Move the single line to the callsite as the name is now misleading, and the purpose is solely to add the request to the execution queue. Here, we can see that if we failed to dispatch the batch from the request, we can forgo flushing the GPU when closing the request. Signed-off-by: Chris Wilson R

[Intel-gfx] [CI 22/26] drm/i915: Use dev_priv consistently through the intel_frontbuffer interface

Rather than a mismash of struct drm_device *dev and struct drm_i915_private *dev_priv being used freely within a function, be consistent and only pass along dev_priv. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [CI 13/26] drm/i915: Record allocated vma size

Tracking the size of the VMA as allocated allows us to dramatically reduce the complexity of later functions (like inserting the VMA in to the drm_mm range manager). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 103 ++

[Intel-gfx] [CI 08/26] drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check

i915_gem_valid_gtt_space() is used after inserting the VMA to double check the list - the location should have been chosen to pass all the restrictions. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 5 + 1 file changed, 1 insertion(+), 4 dele

[Intel-gfx] [CI 18/26] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for i915_gem_object_ggtt_pin(), spare us the confusion and remove it. Removing it now simplifies later patches to change the i915_vma_pin() (and friends) interface. v2: Add a redundant GEM_BUG_ON(!view) to i915_gem_obj_lookup_or_cre

[Intel-gfx] [CI 07/26] drm/i915: Pad GTT views of exec objects up to user specified size

Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden away in the userspace driver, but when we accept po

[Intel-gfx] [CI 20/26] drm/i915: Make fb_tracking.lock a spinlock

We only need a very lightweight mechanism here as the locking is only used for co-ordinating a bitfield. v2: Move the cheap unlikely tests into the caller v3: Move the kerneldoc into the header (now separated out into intel_fronbuffer.h for better kerneldoc and readability) Signed-off-by: Chris W

[Intel-gfx] [CI 17/26] drm/i915: Make i915_vma_pin() small and inline

Not only is i915_vma_pin() called for every single object on every single execbuf, it is usually a simple increment as the VMA is already bound for execution by the GPU. Rearrange the tests for unbound and pin_count overflow so that we can do the increment and test very cheaply and compact enough t

[Intel-gfx] [CI 25/26] drm/i915: Enable lockless lookup of request tracking via RCU

If we enable RCU for the requests (providing a grace period where we can inspect a "dead" request before it is freed), we can allow callers to carefully perform lockless lookup of an active request. However, by enabling deferred freeing of requests, we can potentially hog a lot of memory when deal

[Intel-gfx] [CI 14/26] drm/i915: Wrap vma->pin_count accessors with small inline helpers

In the next few patches, the VMA pinning API is overhauled and to reduce the churn we pull out the update to the accessors into a prep patch. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [CI 21/26] drm/i915: Use atomics to manipulate obj->frontbuffer_bits

The individual bits inside obj->frontbuffer_bits are protected by each plane->mutex, but the whole bitfield may be accessed by multiple KMS operations simultaneously and so the RMW need to be under atomics. However, for updating the single field we do not need to mandate that it be under the struct

[Intel-gfx] [CI 26/26] drm/i915: Export our request as a dma-buf fence on the reservation object

If the GEM objects being rendered with in this request have been exported via dma-buf to a third party, hook ourselves into the dma-buf reservation object so that the third party can serialise with our rendering via the dma-buf fences. Testcase: igt/prime_busy Signed-off-by: Chris Wilson Reviewed

[Intel-gfx] [CI 19/26] drm/i915: Separate intel_frontbuffer into its own header

In view of adding inline functions into the intel_frontbuffer section, we first split the header into its own file so that we can integrate it more easily with kerneldoc. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Daniel Vetter --- Documentation/gpu/i915.rst |

[Intel-gfx] [CI 10/26] drm/i915: Convert 4096 alignment request to 0 for drm_mm allocations

As we always allocate in chunks of 4096 (that being both the PAGE_SIZE and our own GTT_PAGE_SIZE), we know that all results from the drm_mm are aligned to at least 4096. The drm_mm allocator itself is optimised for alignment == 0, and so by converting alignments of 4096 to 0 we can satisfy our own

  1   2   3   >