[Intel-gfx] [PATCH 4/4] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

During a hibernate/resume cycle, the whole system is reset, including the GuC and the doorbell hardware. Then the system is booted up, drivers are loaded, etc -- the GuC firmware may be loaded and set running at this point. But then, the booted kernel is replaced by the hibernated image, and this

Re: [Intel-gfx] [PATCH 01/62] drm/i915: Only start retire worker when idle

On Tue, Jun 07, 2016 at 02:31:07PM +0300, Joonas Lahtinen wrote: > On pe, 2016-06-03 at 17:36 +0100, Chris Wilson wrote: > >  i915_gem_idle_work_handler(struct work_struct *work) > >  { > >   struct drm_i915_private *dev_priv = > > - container_of(work, typeof(*dev_priv),

[Intel-gfx] [PATCH 10/12] drm/i915: Simplify hdmi_12bpc_possible()

From: Ville Syrjälä With the output_types bitmask there's no need to loop through the encoders anymore when checking for HDMI+non-HDMI cloning. v2: Use output_types bitmask Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/12] drm/i915: Replace manual lvds and sdvo/hdmi counting with intel_crtc_has_type()

From: Ville Syrjälä Since we now have the output_types bitmaks in the crtc state, there's no need to iterate through all the encoders to see if an LVDS or SDVO/HDMI encoder might be present. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 09/12] drm/i915: Kill has_dsi_encoder

From: Ville Syrjälä has_dsi_encoder was introduced to indicate that the pipe is driving a DSI encoder. Now that we have the output_types bitmask that can tell us the same thing, let's just kill has_dsi_encoder. v2: Rebase, handle BXT DSI transcoder, rewrote commit

[Intel-gfx] [PATCH 08/12] drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/

From: Ville Syrjälä INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST. Let's just rename it to INTEL_OUTPUT_DP. v2: Rebase Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 06/12] drm/i915: Kill has_dp_encoder from pipe_config

From: Ville Syrjälä Use the new output_types bitmask instead of has_dp_encoder. To make it less oainlful provide a small helper (intel_crtc_has_dp_encoder()) to do the bitsy stuff. v2: Rebase Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 07/12] drm/i915: Replace some open coded intel_crtc_has_dp_encoder()s

From: Ville Syrjälä A bunch of places still look for DP encoders manually. Just call intel_crtc_has_dp_encoder(). Note that many of these places don't look for EDP or DP_MST, but it's still fine to replace them because * for audio we don't enable audio on eDP

[Intel-gfx] [PATCH 12/12] drm/i915: Stop frobbing with DDI encoder->type

From: Ville Syrjälä Now that we have the output_types bitmask in the crtc state, we can use it to indicate in which mode we want to drive the DDI encoders. For pre-DDI output_types will instead indicate what kind of cloning is being done, but as DDI platforms don't

[Intel-gfx] [PATCH 11/12] drm/i915: Check for invalid cloning earlier during modeset

From: Ville Syrjälä Move the encoder cloning check to happen earlier in the modeset. The main benefit will be that the debug output from a failed modeset will be less confusing as output_types can not indicate an invalid configuration during the later computation

[Intel-gfx] [PATCH 00/12] drm/i915: Eliminate DDI encoder->type frobbery

From: Ville Syrjälä DDI encoders changing encoder->type at random points in time is a bit of a problem. Earlier I posted a series [1] to split DDI encoders into separate HDMI and DP encoders, but now that LSPCON is coming we'll anyway need some way to change the

[Intel-gfx] [PATCH 02/12] drm/i915: Remove encoder type checks from MST suspend/resume

From: Ville Syrjälä Now that eDP encoders won't have can_mst==true, we can throw out the encoder type checks from the MST suspend/resume paths. Cc: Dave Airlie Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 01/12] drm/i915: Don't mark eDP encoders as MST capable

From: Ville Syrjälä If we've determined that the encoder is eDP, we shouldn't try to use MST on it. Or at least the code doesn't seem to expect that since there are some type==DP checks in the MST code. Cc: Dave Airlie Signed-off-by: Ville

[Intel-gfx] [PATCH 04/12] drm/i915: Unify intel_pipe_has_type() and intel_pipe_will_have_type()

From: Ville Syrjälä With the introduction of the output_types mask, intel_pipe_has_type() and intel_pipe_will_have_type() are basically the same thing. Replace them with a new intel_crtc_has_type() (identical to intel_pipe_will_have_type() actually). v2: Rebase

[Intel-gfx] [PATCH 03/12] drm/i915: Add output_types bitmask into the crtc state

From: Ville Syrjälä Rather than looping through encoders to see which encoder types are being driven by the pipe, add an output_types bitmask into the crtc state and populate it prior to compute_config and during state readout. v2: Determine output_types before

Re: [Intel-gfx] [PATCH 04/62] drm/i915: Restore waitboost credit to the synchronous waiter

On Wed, Jun 08, 2016 at 11:04:57AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:36:29PM +0100, Chris Wilson wrote: > > Ideally, we want to automagically have the GPU respond to the > > instantaneous load by reclocking itself. However, reclocking occurs > > relatively slowly, and to the

Re: [Intel-gfx] [PATCH 13/62] drm/i915: Derive GEM requests from dma-fence

On Wed, Jun 08, 2016 at 11:14:23AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote: > > static inline struct drm_i915_gem_request * > > +to_request(struct fence *fence) > > +{ > > + /* We assume that NULL fence/request are interoperable */ > > +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

On 08/06/16 09:40, Daniel Vetter wrote: On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: CHV pipe C hits underrun when we get -ve X values of cursor. To avoid this we crop the cursor image for by -ve X value and thus use '0' as least X value. You're talking about "-ve" here and

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

On 08/06/16 11:01, Chris Wilson wrote: On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote: On 03/06/16 17:08, Chris Wilson wrote: With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

On 08/06/16 10:48, Chris Wilson wrote: On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote: +static int intel_breadcrumbs_signaler(void *arg) +{ + struct intel_engine_cs *engine = arg; + struct intel_breadcrumbs *b = >breadcrumbs; + struct signal *signal; + +

Re: [Intel-gfx] [PATCH 29/38] drm/i915: Remove locking for get_tiling

On Wed, Jun 08, 2016 at 12:02:01PM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote: > > 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

Re: [Intel-gfx] [PATCH v2 08/20] drm: msm: Rely on the default ->best_encoder() behavior where appropriate

Hi, On 06/07/2016 05:18 PM, Boris Brezillon wrote: For all outputs except DSI we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us.

Re: [Intel-gfx] [PATCH 37/38] drm/i915: Track pinned VMA

On Fri, Jun 03, 2016 at 05:55:52PM +0100, Chris Wilson wrote: > Treat the VMA as the primary struct responsible for tracking bindings > into the GPU's VM. That is we want to treat the VMA returned after we > pin an object into the VM as the cookie we hold and eventually release > when unpinning.

Re: [Intel-gfx] [PATCH 06/38] drm/i915: Pad GTT views of exec objects up to user specified size

On Wed, Jun 08, 2016 at 11:41:01AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:21PM +0100, Chris Wilson wrote: > > 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

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Fri, Jun 03, 2016 at 05:55:47PM +0100, Chris Wilson wrote: > The error state is purposefully racy as we expect it to be called at any > time and so have avoided any locking whilst capturing the crash dump. > However, with multi-engine GPUs and multiple CPUs, those races can > manifest into

Re: [Intel-gfx] [PATCH 22/38] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

On Wed, Jun 08, 2016 at 11:57:21AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:37PM +0100, Chris Wilson wrote: > > Signed-off-by: Chris Wilson > > Shouldn't we only do this as a last resort, i.e. in the oom notifier? > Commit message is a bit sparse on

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

On Wed, Jun 08, 2016 at 11:59:25AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:42PM +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

Re: [Intel-gfx] [PATCH 29/38] drm/i915: Remove locking for get_tiling

On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote: > 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

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > >With only a single callsite for intel_engine_cs->irq_get and ->irq_put, > >we can reduce the code size by moving the common preamble into the > >caller, and we can also eliminate the

Re: [Intel-gfx] [PATCH 28/38] drm/i915: Remove pinned check from madvise ioctl

On Fri, Jun 03, 2016 at 05:55:43PM +0100, Chris Wilson wrote: > 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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for creating/using Stolen memory backed objects (rev16)

== Series Details == Series: Support for creating/using Stolen memory backed objects (rev16) URL : https://patchwork.freedesktop.org/series/659/ State : failure == Summary == Applying: drm/i915: Add support for mapping an object page by page Applying: drm/i915: Introduce

Re: [Intel-gfx] [PATCH v2 11/20] drm: sti: Rely on the default ->best_encoder() behavior

Hi Boris, Thanks for the patch. Acked-by: Vincent Abriou Vincent On 06/07/2016 01:48 PM, Boris Brezillon wrote: > All outputs have a 1:1 relationship between connectors and encoders > and the driver is relying on the atomic helpers: we can drop the custom >

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

On Fri, Jun 03, 2016 at 05:55:42PM +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

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

On 08/06/16 10:35, Chris Wilson wrote: On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote: On 03/06/16 17:08, Chris Wilson wrote: If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the

Re: [Intel-gfx] [PATCH 22/38] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

On Fri, Jun 03, 2016 at 05:55:37PM +0100, Chris Wilson wrote: > Signed-off-by: Chris Wilson Shouldn't we only do this as a last resort, i.e. in the oom notifier? Commit message is a bit sparse on the motivation here ;-) -Daniel > --- >

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Embed signaling node into the GEM request

On Tue, Jun 07, 2016 at 01:31:25PM +0100, Tvrtko Ursulin wrote: > >@@ -418,20 +423,23 @@ int intel_engine_enable_signaling(struct > >drm_i915_gem_request *request) > > struct intel_engine_cs *engine = request->engine; > > struct intel_breadcrumbs *b = >breadcrumbs; > > struct rb_node

Re: [Intel-gfx] [PATCH 13/38] drm/i915: Move obj->active:5 to obj->flags

On Fri, Jun 03, 2016 at 05:55:28PM +0100, Chris Wilson wrote: > We are motivated to avoid using a bitfield for obj->active for a couple > of reasons. Firstly, we wish to document our lockless read of obj->active > using READ_ONCE inside i915_gem_busy_ioctl() and that requires an > integral type

[Intel-gfx] [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects

From: Ankitprasad Sharma This patch adds support for extending the pread/pwrite functionality for objects not backed by shmem. The access will be made through gtt interface. This will cover objects backed by stolen memory as well as other non-shmem backed objects.

[Intel-gfx] [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace

From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever there is a failure in object allocation. This patch helps user to

[Intel-gfx] [PATCH 11/11] drm/i915: Extend GET_APERTURE ioctl to report available map space

From: Ankitprasad Sharma When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers

[Intel-gfx] [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages

From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like evicting objects to free up enough contiguous space in the vma when

[Intel-gfx] [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT

From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only for buffers allocated from stolen region. v2: Added kernel doc

[Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast

From: Ankitprasad Sharma In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, we try a nonblocking pin for the whole object (since that is fastest if reused), then failing that we try to grab one page in the mappable aperture. It also allows us

[Intel-gfx] [PATCH 10/11] drm/i915: Disable use of stolen area by User when Intel RST is present

From: Ankitprasad Sharma The BIOS RapidStartTechnology may corrupt the stolen memory across S3 suspend due to unalarmed hibernation, in which case we will not be able to preserve the User data stored in the stolen region. Hence this patch tries to identify

[Intel-gfx] [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation

From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and promptly hanging the GPU on resume. We want to utilise stolen for

[Intel-gfx] [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address()

From: Chris Wilson This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with any page within the object. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects

From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be

[Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated over to access the whole object by using space as meagre as page

[Intel-gfx] [PATCH v21 00/11] Support for creating/using Stolen memory backed objects

From: Ankitprasad Sharma This patch series adds support for creating/using Stolen memory backed objects. Despite being a unified memory architecture (UMA) some bits of memory are more equal than others. In particular we have the thorny issue of stolen memory,

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote: > >+static int intel_breadcrumbs_signaler(void *arg) > >+{ > >+struct intel_engine_cs *engine = arg; > >+struct intel_breadcrumbs *b = >breadcrumbs; > >+struct signal *signal; > >+ > >+/* Install ourselves with high

Re: [Intel-gfx] [PATCH 10/38] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote: > Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for > i915_gem_object_ggtt_pin(), spare us the confustion and remove it. > Removing it now simplifies later patches to change the i915_vma_pin() > (and friends)

Re: [Intel-gfx] [PATCH 06/38] drm/i915: Pad GTT views of exec objects up to user specified size

On Fri, Jun 03, 2016 at 05:55:21PM +0100, Chris Wilson wrote: > 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

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > >If we flag the seqno as potentially stale upon receiving an interrupt, > >we can use that information to reduce the frequency that we apply the > >heavyweight coherent seqno read (i.e. if

Re: [Intel-gfx] The vma leak fix from yonder

On Fri, Jun 03, 2016 at 05:36:25PM +0100, Chris Wilson wrote: > Just to see if anyone is awake this series takes us to the VMA leak fix. > Just the tip of the iceberg when it comes to VMA fixes... Read through it. I think it'd be good (although yes, painful) if we could untangle the ring/engine

Re: [Intel-gfx] [PATCH 11/21] drm/i915: Refactor scratch object allocation for gen2 w/a buffer

On Mon, Jun 06, 2016 at 04:09:12PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > > if (INTEL_GEN(dev_priv) >= 5) { > >-ret = intel_init_pipe_control(engine); > >+ret = intel_init_pipe_control(engine, 4096); > > Could be cool to define this

Re: [Intel-gfx] [PATCH 08/21] drm/i915: Use HWS for seqno tracking everywhere

On Mon, Jun 06, 2016 at 03:55:18PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/i915_irq.c > >b/drivers/gpu/drm/i915/i915_irq.c > >index 2a736f4a0fe5..4013ad92cdc6 100644 > >--- a/drivers/gpu/drm/i915/i915_irq.c > >+++

Re: [Intel-gfx] FW: Wrt golden MMIO/CFG snaphot in GVT-g

On pe, 2016-06-03 at 12:36 +, Tian, Kevin wrote: > > > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > Sent: Friday, May 27, 2016 7:32 PM > > > > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote: > > > > > > For me I think maybe i915 could save the snapshot for GVT,

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

On Mon, Jun 06, 2016 at 02:44:41PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:36, 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. > > This one needs all the

Re: [Intel-gfx] [PATCH 14/62] drm/i915: Rename request reference/unreference to get/put

On Fri, Jun 03, 2016 at 05:36:39PM +0100, Chris Wilson wrote: > Now that we derive requests from struct fence, swap over to its > nomenclature for references. It's shorter and more idiomatic across the > kernel. > > s/i915_gem_request_reference/i915_gem_request_get/ >

Re: [Intel-gfx] [PATCH 13/62] drm/i915: Derive GEM requests from dma-fence

On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote: > dma-buf provides a generic fence class for interoperation between > drivers. Internally we use the request structure as a fence, and so with > only a little bit of interfacing we can rebase those requests on top of > dma-buf fences.

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Delay queuing hangcheck to wait-request

On Wed, Jun 08, 2016 at 10:42:58AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote: > > We can forgo queuing the hangcheck from the start of every request to > > until we wait upon a request. This reduces the overhead of every > > request, but may

Re: [Intel-gfx] [PATCH 04/62] drm/i915: Restore waitboost credit to the synchronous waiter

On Fri, Jun 03, 2016 at 05:36:29PM +0100, Chris Wilson wrote: > Ideally, we want to automagically have the GPU respond to the > instantaneous load by reclocking itself. However, reclocking occurs > relatively slowly, and to the client waiting for a result from the GPU, > too late. To compensate

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.7-rc2 next-20160608] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Akshu-Agrawal/Revert-drm-i915-Workaround

Re: [Intel-gfx] [PATCH v3 29/33] drm/i915: Split idling from forcing context switch

On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote: > We only need to force a switch to the kernel context placeholder during > eviction. All other uses of i915_gpu_idle() just want to wait until > existing work on the GPU is idle. Rename i915_gpu_idle() to > i915_gem_wait_for_idle() to avoid

Re: [Intel-gfx] [PATCH v3 23/33] drm/i915: Move module init/exit to i915_pci.c

On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote: > The module init/exit routines are a wrapper around the PCI device > init/exit, so move them across. > > Note that in order to avoid exporting the driver struct, instead of > manipulating driver.features inside i915_init we instead opt to

Re: [Intel-gfx] [PATCH 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

On ke, 2016-06-08 at 09:41 +0300, Ander Conselvan De Oliveira wrote: > On Tue, 2016-06-07 at 21:24 +0300, Imre Deak wrote: > > So far we configured a static lane latency optimization during driver > > loading/resuming. The specification changed at one point and now this > > configuration depends

Re: [Intel-gfx] [PATCH 15/21] drm/i915: Stop setting wraparound seqno on initialisation

On Fri, Jun 03, 2016 at 05:08:47PM +0100, Chris Wilson wrote: > We have testcases to ensure that seqno wraparound works fine, so we can > forgo forcing everyone to encounter seqno wraparound during early > uptime. seqno wraparound incurs a full GPU stall so not forcing it > will eliminate one

[Intel-gfx] [i-g-t RFC 2/3] lib: Capture kcov around ioctls

Use our ioctl overload to enable kcov capture around every ioctl. --- lib/igt_aux.c | 84 +++ lib/igt_aux.h | 5 2 files changed, 84 insertions(+), 5 deletions(-) diff --git a/lib/igt_aux.c b/lib/igt_aux.c index fb1dac2..71067b3

[Intel-gfx] [i-g-t RFC 1/3] lib: Wrap kcov

A small utility for extracting kernel coverage using /sys/kernel/debug/kcov. Signed-off-by: Chris Wilson --- lib/Makefile.sources | 2 + lib/igt_debugfs.c| 20 ++ lib/igt_debugfs.h| 1 + lib/igt_kcov.c | 188

Re: [Intel-gfx] [PATCH v7 10/11] drm/i915: Support LRC context single submission

On ke, 2016-06-08 at 08:04 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:46AM -0400, Zhi Wang wrote: > > > > This patch introduces the support of LRC context single submission. > > As GVT context may come from different guests, which require different > > configuration of render

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Delay queuing hangcheck to wait-request

On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote: > We can forgo queuing the hangcheck from the start of every request to > until we wait upon a request. This reduces the overhead of every > request, but may increase the latency of detecting a hang. Howeever, if > nothing every waits

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: > CHV pipe C hits underrun when we get -ve X values of cursor. To avoid > this we crop the cursor image for by -ve X value and thus use '0' as > least X value. You're talking about "-ve" here and there's absolutely no "-ve" anywhere

Re: [Intel-gfx] [PATCH v7 09/11] drm/i915: Introduce execlist context status change notification

On ti, 2016-06-07 at 23:01 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:45AM -0400, Zhi Wang wrote: > > > > This patch introduces an approach to track the execlist context status > > change. > > > > GVT-g uses GVT context as the "shadow context". The content inside GVT > > context

Re: [Intel-gfx] [PATCH v7 08/11] drm/i915: Make addressing mode bits in context descriptor configurable

On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > Currently the addressing mode bit in context descriptor is statically > generated from the configuration of system-wide PPGTT usage model. > > GVT-g will load the PPGTT shadow page table by itself and probably one > guest is using a different

Re: [Intel-gfx] [PATCH v7 07/11] drm/i915: Make ring buffer size of a LRC context configurable

On ke, 2016-06-08 at 08:08 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:43AM -0400, Zhi Wang wrote: > > > > This patch introduces an option for configuring the ring buffer size > > of a LRC context after the context creation. > > > > Signed-off-by: Zhi Wang >

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail"

== Series Details == Series: series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail" URL : https://patchwork.freedesktop.org/series/8431/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_dp_mst.o CC [M] drivers/gpu/drm/i915/intel_dp.o CC [M]

Re: [Intel-gfx] [RFC 00/12] Support for sustained capturing of GuC firmware logs

On Fri, Jun 03, 2016 at 11:20:19AM +0100, Chris Wilson wrote: > On Fri, Jun 03, 2016 at 03:44:09PM +0530, Goel, Akash wrote: > > > > > > On 6/3/2016 12:45 PM, Daniel Vetter wrote: > > >On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote: > > >>On Thu, 2016-06-02 at 10:16 +, Daniel

Re: [Intel-gfx] [PATCH v7 05/11] drm/i915: gvt: Introduce the basic architecture of GVT-g

On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > This patch introduces the very basic framework of GVT-g device model, > includes basic prototypes, definitions, initialization. > > v7: > - Refine the URL link in Kconfig. (Joonas) > - Refine the introduction of GVT-g host support in Kconfig.

[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail"

This reverts commit ef8dd37af85a8f37ca3a29074647511e52c56181. Will use cropped cursor image for -ve co-ordinates instead of using swcursor. Advantages of cropped cursor being, it will work for non X11 based platform like Chrome and also will use hwcursor. Signed-off-by: Akshu Agrawal

[Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

CHV pipe C hits underrun when we get -ve X values of cursor. To avoid this we crop the cursor image for by -ve X value and thus use '0' as least X value. Signed-off-by: Akshu Agrawal --- drivers/gpu/drm/i915/intel_display.c | 113 +++

Re: [Intel-gfx] [PATCH v7 01/11] drm/i915: Factor out i915_pvinfo.h

Sure. Moving code in one patch, "offsetof()" guy will be in another patch > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, June 08, 2016 10:55 AM > To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan >

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915/guc: fix GuC loading/submission check

On 07/06/16 21:00, Chris Wilson wrote: On Tue, Jun 07, 2016 at 02:23:34PM +0100, Tvrtko Ursulin wrote: On 07/06/16 11:54, Dave Gordon wrote: On 07/06/16 09:43, Patchwork wrote: == Series Details == Series: series starting with [1/3] drm/i915/guc: fix GuC loading/submission check URL :

Re: [Intel-gfx] [PATCH v7 08/11] drm/i915: Make addressing mode bits in context descriptor configurable

Good idea. :) > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, June 08, 2016 10:13 AM > To: Wang, Zhi A > Cc: Lv, Zhiyuan ; Tian, Kevin ; > tvrtko.ursu...@linux.intel.com;

Re: [Intel-gfx] [PATCH v7 04/11] drm/i915: Add teardown path in intel_vgt_ballon()

Patch title s/ballon/balloon/. On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > This function needs to be changed to have a proper goto teardown path. > Destructors/fini functions are only expected to be called after a > successful initialization, so calling it at random phase in init function

Re: [Intel-gfx] [PATCH v7 03/11] drm/i915: Fold vGPU active check into inner functions

OK. Will do in the next version. :) > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, June 08, 2016 11:05 AM > To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan > ; Tian, Kevin

Re: [Intel-gfx] [PATCH v7 03/11] drm/i915: Fold vGPU active check into inner functions

On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > v5: > - Let functions take struct drm_i915_private *. (Tvrtko) > > - Fold vGPU related active check into the inner functions. (Kevin) > I already reviewed this patch, so you should add Reviewed-by: and Cc: tags. Also good to add Cc: tag for

Re: [Intel-gfx] [PATCH v7 02/11] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page

On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > To get the offset of the members in PVINFO page, offsetof() looks much > better than the tricky approach in current code. > > v7: > > - Move "offsetof()" modification into a dedicated patch. (Joonas) > > Signed-off-by: Zhi Wang

Re: [Intel-gfx] [PATCH v7 01/11] drm/i915: Factor out i915_pvinfo.h

On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g > host (GVT-g kernel device model), factor it out for better code structure. > > v7: > - Split the "offsetof" modification into a dedicated patch. (Joonas) > > v3: > -

Re: [Intel-gfx] [PATCH v6 7/9] drm/i915: Introduce execlist context status change notification

On ti, 2016-06-07 at 15:29 +, Wang, Zhi A wrote: > > > > > -Original Message- > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > Sent: Friday, June 03, 2016 12:40 PM > > To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; > >

Re: [Intel-gfx] [PATCH v7 08/11] drm/i915: Make addressing mode bits in context descriptor configurable

On Tue, Jun 07, 2016 at 11:18:44AM -0400, Zhi Wang wrote: > Currently the addressing mode bit in context descriptor is statically > generated from the configuration of system-wide PPGTT usage model. > > GVT-g will load the PPGTT shadow page table by itself and probably one > guest is using a

Re: [Intel-gfx] [PATCH v7 07/11] drm/i915: Make ring buffer size of a LRC context configurable

On Tue, Jun 07, 2016 at 11:18:43AM -0400, Zhi Wang wrote: > This patch introduces an option for configuring the ring buffer size > of a LRC context after the context creation. > > Signed-off-by: Zhi Wang > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + >

Re: [Intel-gfx] [PATCH v7 10/11] drm/i915: Support LRC context single submission

On Tue, Jun 07, 2016 at 11:18:46AM -0400, Zhi Wang wrote: > This patch introduces the support of LRC context single submission. > As GVT context may come from different guests, which require different > configuration of render registers. It can't be combined into a dual ELSP > submission combo. >

Re: [Intel-gfx] [PATCH v7 11/11] drm/i915: Introduce GVT context creation API

On Tue, Jun 07, 2016 at 11:18:47AM -0400, Zhi Wang wrote: > GVT workload scheduler needs special host LRC contexts, the so called > "shadow LRC context" to submit guest workload to host i915. During the > guest workload submission, workload scheduler fills the shadow LRC > context with the content

Re: [Intel-gfx] [PATCH 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

On Tue, 2016-06-07 at 21:24 +0300, Imre Deak wrote: > So far we configured a static lane latency optimization during driver > loading/resuming. The specification changed at one point and now this > configuration depends on the lane count, so move the configuration > to modeset time accordingly. >

<    1   2