Re: [Intel-gfx] [PATCH 0/3] LPSS PWM support for devices that support it

On 12 January 2016 at 08:59, Shobhit Kumar wrote: > Not sending yet to pwm mailing list as this is all untested. C.B. please > test the patches and see if they work at all for you. For testing Please > enable - > > CONFIG_PWM_LPSS=y > CONFIG_PWM_LPSS_PLATFORM=y I

Re: [Intel-gfx] [PATCH v4 00/38] GPU scheduler for i915 driver

> From: Gordon, David S > Sent: Tuesday, January 12, 2016 9:49 PM > > On 12/01/2016 11:43, John Harrison wrote: > > On 12/01/2016 04:37, Tian, Kevin wrote: > >>> From: john.c.harri...@intel.com > >>> Sent: Tuesday, January 12, 2016 2:42 AM > >>> > >>> From: John Harrison

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra)

Re: [Intel-gfx] [PATCH 0/3] LPSS PWM support for devices that support it

On 01/13/2016 11:00 AM, C. B. wrote: On 12 January 2016 at 08:59, Shobhit Kumar wrote: Not sending yet to pwm mailing list as this is all untested. C.B. please test the patches and see if they work at all for you. For testing Please enable - CONFIG_PWM_LPSS=y

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == HEAD is now at a907968 drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Applying: drm: kerneldoc for drm_fops.c Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 drm: kerneldoc for drm_fops.c

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE Test kms_pipe_crc_basic: Subgroup

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

On Mon, 2016-01-11 at 21:29 +, Chris Wilson wrote: > On Mon, Jan 11, 2016 at 05:15:54PM +, Tvrtko Ursulin wrote: > > > Is that not what was written? I take it my telepathy isn't working > > > again. > > > > Sorry not a new loop, new case in a old loop. This is the hunk I think > > is not

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

On Tue, 2016-01-12 at 09:34 +0100, Daniel Vetter wrote: > On Mon, Jan 11, 2016 at 06:12:12PM -0700, Jonathan Corbet wrote: > > On Sat, 12 Dec 2015 12:13:45 +0100 > > Daniel Vetter wrote: > > > > > I just figured there's no way this could get it, and I'd > > > much rather improve

Re: [Intel-gfx] [PATCH 07/22] drm/armada: Remove NULL open/pre/postclose hooks

On Tue, Jan 12, 2016 at 11:51:58AM +, Russell King - ARM Linux wrote: > On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote: > > The compiler will do this, but the void hits when grepping all the > > hooks for a subsystem wide audit are slightly annoying. So remove them > > for next

Re: [Intel-gfx] [PATCH] drm/i915/skl: Use proper plane dimensions for DDB and WM calculations

On Mon, Jan 11, 2016 at 02:13:06PM -0800, Matt Roper wrote: > On Mon, Jan 11, 2016 at 09:31:03PM +0200, Ville Syrjälä wrote: > > On Mon, Dec 21, 2015 at 07:31:17AM -0800, Matt Roper wrote: > > > In commit > > > > > > commit 024c9045221fe45482863c47c4b4c47d37f97cbf > > > Author:

Re: [Intel-gfx] [PATCH v4 38/38] drm/i915: Allow scheduler to manage inter-ring object synchronisation

On 11/01/2016 22:07, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:43:07PM +, john.c.harri...@intel.com wrote: From: John Harrison The scheduler has always tracked batch buffer dependencies based on DRM object usage. This means that it will not submit a batch

[Intel-gfx] [PATCH v2 2/7] drm/i915: Do not call API requiring struct_mutex where it is not available

From: Tvrtko Ursulin LRC code was calling GEM API like i915_gem_obj_ggtt_offset from places where the struct_mutex cannot be grabbed (irq handlers). To avoid that this patch caches some interesting bits and values in the engine and context structures. Some usages are

Re: [Intel-gfx] [PATCH v3 3/7] drm/i915: Cache ringbuffer GTT VMA

On Tue, Jan 12, 2016 at 11:42:39AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Purpose is to avoid calling i915_gem_obj_ggtt_offset from the > interrupt context without the big lock held. > > v2: Renamed gtt_start to gtt_offset. (Daniel Vetter) > v3: Cache

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add per context timelines to fence object

On Tue, Jan 12, 2016 at 11:03:08AM +, John Harrison wrote: > On 11/01/2016 22:58, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 02:47:33PM -0800, Jesse Barnes wrote: > >>On 01/11/2016 11:03 AM, John Harrison wrote: > >>>On 08/01/2016 22:05, Chris Wilson wrote: > On Fri, Jan 08, 2016 at

[Intel-gfx] [PATCH v2 4/7] drm/i915: Cache LRC state page in the context

From: Tvrtko Ursulin LRC lifetime is well defined so we can cache the page pointing to the object backing store in the context in order to avoid walking over the object SG page list from the interrupt context without the big lock held. v2: Also cache the mapping.

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On 12/01/2016 11:28, Chris Wilson wrote: On Tue, Jan 12, 2016 at 11:11:20AM +, John Harrison wrote: On 12/01/2016 00:20, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote: From: John Harrison A later patch in this

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Support for creating Stolen memory backed objects

On Tue, Dec 22, 2015 at 11:50:47AM +0530, ankitprasad.r.sha...@intel.com wrote: > @@ -456,6 +457,21 @@ struct drm_i915_gem_create { >*/ > __u32 handle; > __u32 pad; > + /** > + * Requested flags (currently used for placement > + * (which memory domain)) > + *

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: Cache LRC state page in the context

On 12/01/16 12:12, Chris Wilson wrote: On Tue, Jan 12, 2016 at 11:56:11AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin LRC lifetime is well defined so we can cache the page pointing to the object backing store in the context in order to avoid walking over the

Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties

On Mon, Jan 11, 2016 at 08:37:09PM +, Daniel Stone wrote: > Hi, > > On 5 January 2016 at 10:23, Daniel Vetter wrote: > > On Wed, Dec 23, 2015 at 09:47:00AM +, Daniel Stone wrote: > >> It's not even a legacy vs. atomic thing, this can happen in > >> pure-atomic as well.

Re: [Intel-gfx] [PATCH v4 00/38] GPU scheduler for i915 driver

On 12/01/2016 04:37, Tian, Kevin wrote: From: john.c.harri...@intel.com Sent: Tuesday, January 12, 2016 2:42 AM From: John Harrison Implemented a batch buffer submission scheduler for the i915 DRM driver. The general theory of operation is that when batch buffers

Re: [Intel-gfx] [PATCH v4 18/38] drm/i915: Added scheduler support to __wait_request() calls

On 11/01/2016 23:14, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:47PM +, john.c.harri...@intel.com wrote: From: John Harrison The scheduler can cause batch buffers, and hence requests, to be submitted to the ring out of order and asynchronously to their

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On 07/01/16 16:53, Chris Wilson wrote: On Thu, Jan 07, 2016 at 08:49:38AM -0800, Jesse Barnes wrote: On 01/07/2016 03:58 AM, Chris Wilson wrote: On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote: There are a number of places where the driver needs a request, but isn't working on

Re: [Intel-gfx] [PATCH 073/190] drm/i915: Introduce i915_gem_active for request tracking

On 12/01/16 11:01, Chris Wilson wrote: On Tue, Jan 12, 2016 at 10:04:20AM +, Tvrtko Ursulin wrote: Perhaps then leave the structure name as is and just rename the function to i915_gem_request_assign_active? I think that describes better what is actually happening.

Re: [Intel-gfx] [PATCH 076/190] drm/i915: Rename vma->*_list to *_link for consistency

On 11/01/16 09:17, Chris Wilson wrote: Elsewhere we have adopted the convention of using '_link' to denote elements in the list (and '_list' for the actual list_head itself), and that the name should indicate which list the link belongs to (and preferrably not just where the link is being

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote: > There are a number of places where the driver needs a request, but isn't > working on behalf of any specific user or in a specific context. At > present, we associate them with the per-engine default context. A future > patch will

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: abolish separate per-ring default_context pointers

On Thu, Jan 07, 2016 at 10:20:51AM +, Dave Gordon wrote: > Now that we've eliminated a lot of uses of ring->default_context, > we can eliminate the pointer itself. > > All the engines share the same default intel_context, so we can just > keep a single reference to it in the dev_priv

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On Tue, Jan 12, 2016 at 02:50:28PM +0100, Daniel Vetter wrote: > On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote: > > There are a number of places where the driver needs a request, but isn't > > working on behalf of any specific user or in a specific context. At > > present, we

Re: [Intel-gfx] [PATCH 073/190] drm/i915: Introduce i915_gem_active for request tracking

On Tue, Jan 12, 2016 at 01:44:13PM +, Tvrtko Ursulin wrote: > > On 12/01/16 11:01, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 10:04:20AM +, Tvrtko Ursulin wrote: > >>Perhaps then leave the structure name as is and just rename the > >>function to i915_gem_request_assign_active? I think

Re: [Intel-gfx] [PATCH 024/190] drm/i915: Replace manual barrier() with READ_ONCE() in HWS accessor

Chris Wilson writes: > When reading from the HWS page, we use barrier() to prevent the compiler > optimising away the read from the volatile (may be updated by the GPU) > memory address. This is more suited to READ_ONCE(); make it so. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On 12/01/2016 14:04, Daniel Vetter wrote: On Tue, Jan 12, 2016 at 11:50:34AM +, John Harrison wrote: On 12/01/2016 11:28, Chris Wilson wrote: On Tue, Jan 12, 2016 at 11:11:20AM +, John Harrison wrote: On 12/01/2016 00:20, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:31PM +,

Re: [Intel-gfx] [PATCH] drm/i915: reboot notifier delay for eDP panels

On Mon, Jan 11, 2016 at 01:52:17PM -0800, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Add reboot notifier for all platforms. This guarantees T12 delay > compliance during reboot cycles when pre-os enables the panel within > 500ms. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 073/190] drm/i915: Introduce i915_gem_active for request tracking

On 12/01/16 11:01, Chris Wilson wrote: On Tue, Jan 12, 2016 at 10:04:20AM +, Tvrtko Ursulin wrote: Perhaps then leave the structure name as is and just rename the function to i915_gem_request_assign_active? I think that describes better what is actually happening.

Re: [Intel-gfx] [PATCH v4 00/38] GPU scheduler for i915 driver

On 12/01/2016 11:43, John Harrison wrote: On 12/01/2016 04:37, Tian, Kevin wrote: From: john.c.harri...@intel.com Sent: Tuesday, January 12, 2016 2:42 AM From: John Harrison Implemented a batch buffer submission scheduler for the i915 DRM driver. The general

Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.

On Mon, Jan 11, 2016 at 02:55:37PM -0800, abhay.ku...@intel.com wrote: > From: Abhay Kumar > > Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) > if this time is already spent in suspend/poweron time. > > v2: Use CLOCK_BOOTTIME and remove jiffies

Re: [Intel-gfx] [PATCH v4 10/38] drm/i915: Force MMIO flips when scheduler enabled

On Tue, Jan 12, 2016 at 11:19:26AM +, John Harrison wrote: > On 11/01/2016 22:16, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 06:42:39PM +, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>MMIO flips are the preferred mechanism now but more

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote: > But we were removing the engine->default_context as it complicated the > rest of the code. I strongly prefer keeping the contexts explicit as > context separation should be first and foremost in the driver. $ git grep kernel_context

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

Chris Wilson writes: > On Tue, Jan 12, 2016 at 12:05:06PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> > - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE | >> > - PIPE_CONTROL_WRITE_FLUSH | >>

Re: [Intel-gfx] [PATCH] drm/i915: Assign crtc correctly in load detection.

Op 12-01-16 om 13:34 schreef Daniel Vetter: > On Tue, Jan 12, 2016 at 12:35:59PM +0100, Maarten Lankhorst wrote: >> drm_atomic_set_crtc_for_connector should be used, >> and crtc->primary->crtc is assigned by atomic_commit. >> >> Rely on the helpers for setting this correctly, so >> connector_mask

Re: [Intel-gfx] [PATCH 145/190] drm/i915: Stop discarding GTT cache-domain on unbind vma

On ma, 2016-01-11 at 11:00 +, Chris Wilson wrote: > Since > > commit 43566dedde54f9729113f5f9fde77d53e75e61e9 > Author: Chris Wilson > Date: Fri Jan 2 16:29:29 2015 +0530 > > drm/i915: Broaden application of set-domain(GTT) > > we allowed objects to be in

Re: [Intel-gfx] Intel-gfx Digest, Vol 96, Issue 26

Hi, Can someone review the patches in the below mail? PFB the link to the same: https://patchwork.freedesktop.org/series/369/#rev5 Thanks and Regards, Shubhangi Shrivastava. On Tuesday 05 January 2016 06:28 PM, intel-gfx-requ...@lists.freedesktop.org wrote: Send Intel-gfx

Re: [Intel-gfx] [PATCH 074/190] drm/i915: Rename request->list to link for consistency

On 11/01/16 09:17, Chris Wilson wrote: We use "list" to denote the list and "link" to denote an element on that list. Rename request->list to match this idiom. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: tidy up a few leftovers

On Thu, Jan 07, 2016 at 10:20:52AM +, Dave Gordon wrote: > There are a few bits of code which the transformations implemented by > the previous patch reveal to be suboptimal, once the notion of a per- > ring default context has gone away. So this tidies up the leftovers. > > It could have

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On Tue, Jan 12, 2016 at 11:50:34AM +, John Harrison wrote: > On 12/01/2016 11:28, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 11:11:20AM +, John Harrison wrote: > >>On 12/01/2016 00:20, Chris Wilson wrote: > >>>On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote: >

Re: [Intel-gfx] [PATCH 16/22] drm/omap: Nuke close hooks

On 11/01/16 23:41, Daniel Vetter wrote: > Again since the core takes care of this we can remove them. While at > it also remove the postclose hook, it's empty. > > v2: Laurent pointed me at even more code to delete. > > Cc: Laurent Pinchart > Cc: Tomi

Re: [Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

On 11/01/16 23:41, Daniel Vetter wrote: > Again since the drm core takes care of event unlinking/disarming this > is now just needless code. > > v2: Fixup misplaced hunks. > > Cc: Rob Clark > Acked-by: Daniel Stone > Reviewed-by: Alex Deucher

Re: [Intel-gfx] [PATCH 006/190] drm/i915: Add GEM debugging Kconfig option

On 11/01/16 09:16, Chris Wilson wrote: Currently there is a #define to enable extra BUG_ON for debugging requests and associated activities. I want to expand its use to cover all of GEM internals (so that we can saturate the code with asserts). We can add a Kconfig option to make it easier to

[Intel-gfx] [PATCH 1/7] drm/i915: Pass modifier instead of tiling_mode to gen4_compute_page_offset()

From: Ville Syrjälä In preparation for handling more than X tiling, pass the fb modifier to gen4_compute_page_offset() instead of the obj->tiling_mode. Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH v3 2/7] drm/i915: Factor out intel_tile_width()

From: Ville Syrjälä Pull the tile width calculations from intel_fb_stride_alignment() into a new function intel_tile_width(). Also take the opportunity to pass aroun dev_priv instead of dev to intel_fb_stride_alignment(). v2: Reorder argumnents to be more

[Intel-gfx] [PATCH 0/7] drm/i915: Reviewed fb offsets[] prep patches

From: Ville Syrjälä Here's a repost of some already reviewed patches from my larger fb offsets[] series [1] from last year, for the sake of the CI system. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/078050.html Ville Syrjälä (7): drm/i915:

[Intel-gfx] [PATCH 5/7] drm/i915: Use intel_tile_{size, width, height}() in intel_gen4_compute_page_offset()

From: Ville Syrjälä Make intel_gen4_compute_page_offset() ready for other tiling formats besied X-tile by getting the tile dimensions through intel_tile_{size,width,height}(). Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH 7/7] drm/i915: Refactor intel_surf_alignment()

From: Ville Syrjälä Pull the code to determine the surface alignment for both linear and tiled surfaces into a separate function intel_surf_alignment(). This will be used not only for the vma alignment but actually aligning the plane SURF once SKL+ starts using

[Intel-gfx] [PATCH v2 4/7] drm/i915: change intel_fill_fb_ggtt_view() to use the real tile size

From: Ville Syrjälä Use the actual tile size as to compute stuff in intel_fill_fb_ggtt_view() instead of assuming it's PAGE_SIZE. I suppose it doesn't matter since we don't use the results on gen2 platforms where the tile size is 2k. v2: Update due to CbCr plane

[Intel-gfx] [PATCH v2 6/7] drm/i915: s/intel_gen4_compute_page_offset/intel_compute_tile_offset/

From: Ville Syrjälä Since intel_gen4_compute_page_offset() can now handle tiling formats all the way down to gen2, rename it to intel_compute_tile_offset(). Not that we actually use it on gen2/3 since there's no DSPSURF etc. registers which would take a page

Re: [Intel-gfx] [PATCH 004/190] drm/i915: Fix some invalid requests cancellations

On 11/01/16 09:16, Chris Wilson wrote: As we add the VMA to the request early, it may be cancelled during execbuf reservation. This will leave the context object pointing to a dangling request; i915_wait_request() simply skips the wait and so we may unbind the object whilst it is still active.

[Intel-gfx] [PATCH v2 3/7] drm/i915: Redo intel_tile_height() as intel_tile_size() / intel_tile_width()

From: Ville Syrjälä I find more usual to think about tile widths than heights, so changing the intel_tile_height() to calculate the tile height as tile_size/tile_width is easier than the opposite to the poor brain. v2: Reorder arguments for consistency

Re: [Intel-gfx] [PATCH 053/190] drm/i915: Convert i915_semaphores_is_enabled over to early sanitize

On 11/01/16 09:17, Chris Wilson wrote: Rather than recomputing whether semaphores are enabled, we can do that computation once during early initialisation as the i915.semaphores module parameter is now read-only. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH 07/11] drm/i915: Store rawclk_freq in dev_priv

On Tue, Dec 01, 2015 at 05:43:33PM +0200, Jani Nikula wrote: > On Tue, 01 Dec 2015, Ville Syrjälä wrote: > > On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote: > >> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote: > >> > From: Ville Syrjälä

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 9a47f23e3744929b9b222cb750994723fff0e5ee drm-intel-nightly: 2016y-01m-12d-16h-55m-40s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE pass -> DMESG-WARN

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Extract vfunc setup from logical ring initializers

On Tue, Jan 12, 2016 at 05:32:34PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Majority of them was duplicated code and only render ring > currently overrides some of them. We can save some lines of > code and also take away the confusion on why bsd2 did not

Re: [Intel-gfx] [PATCH v4 10/38] drm/i915: Force MMIO flips when scheduler enabled

On Tue, Jan 12, 2016 at 03:07:03PM +0100, Daniel Vetter wrote: > On Tue, Jan 12, 2016 at 11:19:26AM +, John Harrison wrote: > > On 11/01/2016 22:16, Chris Wilson wrote: > > >On Mon, Jan 11, 2016 at 06:42:39PM +, john.c.harri...@intel.com wrote: > > >>From: John Harrison

Re: [Intel-gfx] [PATCH 073/190] drm/i915: Introduce i915_gem_active for request tracking

On Tue, Jan 12, 2016 at 10:04:20AM +, Tvrtko Ursulin wrote: > Perhaps then leave the structure name as is and just rename the > function to i915_gem_request_assign_active? I think that describes > better what is actually happening. i915_gem_request_update_active()? request_assign_active()

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i7k-2) UNSTABLE Test kms_pipe_crc_basic: Subgroup

Re: [Intel-gfx] [PATCH v4 21/38] drm/i915: Added a module parameter for allowing scheduler overrides

On Tue, Jan 12, 2016 at 11:34:45AM +, John Harrison wrote: > On 11/01/2016 22:24, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 06:42:50PM +, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>It can be useful to be able to disable certain

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

Chris Wilson writes: > By using the same address for storing the HWS on every platform, we can > remove the platform specific vfuncs and reduce the get-seqno routine to > a single read of a cached memory location. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Don't need a timer to wake us up

On 11/01/16 14:33, Chris Wilson wrote: On Mon, Jan 11, 2016 at 02:08:39PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin We can avoid open-coding the schedule wake-up since commit 9cff8adeaa34b5d2802f03f89803da57856b3b72 Author: NeilBrown

Re: [Intel-gfx] [PATCH v4 12/38] drm/i915: Added scheduler hook into i915_gem_request_notify()

On 11/01/2016 22:14, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:41PM +, john.c.harri...@intel.com wrote: From: John Harrison The scheduler needs to know when requests have completed so that it can keep its own internal state up to date and can submit new

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On 06/01/16 20:53, yu@intel.com wrote: From: Alex Dai During driver unloading, the guc_client created for command submission needs to be released to avoid memory leak. Signed-off-by: Alex Dai --- drivers/gpu/drm/i915/i915_guc_submission.c | 3 +++ 1

Re: [Intel-gfx] [PATCH v4 10/38] drm/i915: Force MMIO flips when scheduler enabled

On 11/01/2016 22:16, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:39PM +, john.c.harri...@intel.com wrote: From: John Harrison MMIO flips are the preferred mechanism now but more importantly, Says who? I asked this exact question at the linux

Re: [Intel-gfx] [PATCH] drm/i915: Assign crtc correctly in load detection.

On Tue, Jan 12, 2016 at 12:35:59PM +0100, Maarten Lankhorst wrote: > drm_atomic_set_crtc_for_connector should be used, > and crtc->primary->crtc is assigned by atomic_commit. > > Rely on the helpers for setting this correctly, so > connector_mask gets updated too. > > Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: Cache LRC state page in the context

On Tue, Jan 12, 2016 at 11:56:11AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > LRC lifetime is well defined so we can cache the page pointing > to the object backing store in the context in order to avoid > walking over the object SG page list from the

Re: [Intel-gfx] [PATCH v4 21/38] drm/i915: Added a module parameter for allowing scheduler overrides

On 11/01/2016 22:24, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:50PM +, john.c.harri...@intel.com wrote: From: John Harrison It can be useful to be able to disable certain features (e.g. the entire scheduler) via a module parameter for debugging purposes.

Re: [Intel-gfx] [PATCH 020/190] drm/i915: Remove the lazy_coherency parameter from request-completed?

On Tue, Jan 12, 2016 at 12:27:05PM +0200, Mika Kuoppala wrote: > > for_each_ring(ring, dev_priv, i) { > > - seqno[i] = ring->get_seqno(ring); > > acthd[i] = intel_ring_get_active_head(ring); > > + seqno[i] = ring->get_seqno(ring); > > Oh! Perhaps I am overly

[Intel-gfx] [PATCH] drm/i915: Assign crtc correctly in load detection.

drm_atomic_set_crtc_for_connector should be used, and crtc->primary->crtc is assigned by atomic_commit. Rely on the helpers for setting this correctly, so connector_mask gets updated too. Signed-off-by: Maarten Lankhorst --- Should this be applied to

Re: [Intel-gfx] [PATCH v4 06/38] drm/i915: Re-instate request->uniq because it is extremely useful

On 11/01/2016 22:04, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:35PM +, john.c.harri...@intel.com wrote: From: John Harrison The seqno value cannot always be used when debugging issues via trace points. This is because it can be reset back to start,

Re: [Intel-gfx] [PATCH v2 02/10] drm/i915: Cleanup phys status page too

On Mon, Jan 11, 2016 at 08:48:32PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Restore the lost phys status page cleanup. > > Fixes the following splat with DMA_API_DEBUG=y: Oh, we should enable this in our CI. Can you please shoot a

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Cache LRCA in the context

On 11/01/16 19:41, Dave Gordon wrote: On 11/01/16 08:38, Daniel Vetter wrote: On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin We are not allowed to call i915_gem_obj_ggtt_offset from irq context without the big kernel lock held.

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

On Tue, Jan 12, 2016 at 12:05:06PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE | > > - PIPE_CONTROL_WRITE_FLUSH | > > -

Re: [Intel-gfx] [PATCH 07/22] drm/armada: Remove NULL open/pre/postclose hooks

On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote: > The compiler will do this, but the void hits when grepping all the > hooks for a subsystem wide audit are slightly annoying. So remove them > for next time around. I'll try to remember to queue this after -rc1, though a reminder

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: Cache LRC state page in the context

On Tue, Jan 12, 2016 at 12:54:25PM +, Tvrtko Ursulin wrote: > > On 12/01/16 12:12, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 11:56:11AM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>LRC lifetime is well defined so we can cache the page pointing

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-WARN (byt-nuc) Test pm_rpm: Subgroup

Re: [Intel-gfx] [PATCH 08/22] drm/gma500: Remove empty preclose hook

On Mon, Jan 11, 2016 at 10:41 PM, Daniel Vetter wrote: > I'm auditing them all, empty ones just confuse ... > > Cc: Patrik Jakobsson > Acked-by: Daniel Stone > Reviewed-by: Alex Deucher >

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

On Mon, Jan 11, 2016 at 06:12:12PM -0700, Jonathan Corbet wrote: > On Sat, 12 Dec 2015 12:13:45 +0100 > Daniel Vetter wrote: > > > I just figured there's no way this could get it, and I'd > > much rather improve the docs themselves than trying to convince core > > kernel folks

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move VBT based TV presence check to intel_bios.c

On Mon, Jan 11, 2016 at 09:54:37PM +0200, Jani Nikula wrote: > Hide knowledge about VBT child devices in intel_bios.c. > > Signed-off-by: Jani Nikula Assuming you copypasted correctly ;-) Reviewed-by: Daniel Vetter > --- >

Re: [Intel-gfx] [PATCH 073/190] drm/i915: Introduce i915_gem_active for request tracking

On 11/01/16 22:49, Chris Wilson wrote: On Mon, Jan 11, 2016 at 05:32:27PM +, Tvrtko Ursulin wrote: +struct i915_gem_active { + struct drm_i915_gem_request *request; +}; + +static inline void +i915_gem_request_mark_active(struct drm_i915_gem_request *request, +

Re: [Intel-gfx] [PATCH 020/190] drm/i915: Remove the lazy_coherency parameter from request-completed?

Chris Wilson writes: > Now that we have split out the seqno-barrier from the > engine->get_seqno() callback itself, we can move the users of the > seqno-barrier to the required callsites simplifying the common code and > making the required workaround handling much more

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add per context timelines to fence object

On 11/01/2016 22:58, Chris Wilson wrote: On Mon, Jan 11, 2016 at 02:47:33PM -0800, Jesse Barnes wrote: On 01/11/2016 11:03 AM, John Harrison wrote: On 08/01/2016 22:05, Chris Wilson wrote: On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote: From: John Harrison

[Intel-gfx] [PATCH v3 3/7] drm/i915: Cache ringbuffer GTT VMA

From: Tvrtko Ursulin Purpose is to avoid calling i915_gem_obj_ggtt_offset from the interrupt context without the big lock held. v2: Renamed gtt_start to gtt_offset. (Daniel Vetter) v3: Cache the VMA instead of address. (Chris Wilson) Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On 12/01/2016 00:20, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote: From: John Harrison A later patch in this series re-organises the batch buffer submission code. Part of that is to reduce the scope of a pm_get/put

Re: [Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Mon, 2016-01-11 at 17:53 +, R, Durgadoss wrote: > > -Original Message- > > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > > Sent: Monday, January 11, 2016 8:46 PM > > To: R, Durgadoss; intel-gfx@lists.freedesktop.org > > Subject: Re: [PATCH 7/7] drm/i915/dp:

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On Tue, Jan 12, 2016 at 11:11:20AM +, John Harrison wrote: > On 12/01/2016 00:20, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>A later patch in this series re-organises the batch

Re: [Intel-gfx] [PATCH 00/10] drm/i915: Fixes from my attempt at running igt on gen2

On Mon, Dec 14, 2015 at 06:23:39PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > It's been a while since I last ran igt on gen2, so I figured I'd > give it a shot. 855 had some failures, 830 no longer worked at > all. So I went ahead and

[Intel-gfx] RPM wakelock ref not held during HW access

Hello, -mmots 4.4.0-mm1-dbg-00602-g776bd09 [ 5331.509087] WARNING: CPU: 0 PID: 359 at drivers/gpu/drm/i915/intel_drv.h:1446 gen6_read32+0x7b/0x253 [i915]() [ 5331.509091] RPM wakelock ref not held during HW access [ 5331.509093] Modules linked in: [ 5331.509182] CPU: 0 PID: 359 Comm: Xorg Not

[Intel-gfx] [PATCH] drm/i915: Handle error paths during watermark sanitization properly (v3)

sanitize_watermarks() does not properly handle errors returned by drm_atomic_helper_duplicate_state(). Make failures drop locks before returning. We also change the lock of connection_mutex to a drm_modeset_lock_all_ctx() to make sure any EDEADLK's are handled earlier. v2: Change call to lock

Re: [Intel-gfx] [PATCH 00/15] drm/i915: Cure DDI from multiple personality disorder

On Tue, Dec 08, 2015 at 07:59:35PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > While debugging problems on DDI platforms I got tired of the crap > caused by the the dual personality DDI encoders, so I went ahead > and split them into

[Intel-gfx] [PATCH 1/3] drm/i915: Encapsulate the pwm_device in a pwm_info structure

pwm_info helps in encapsulating the PWM period_ns values and will form basis of adding new pwm devices which can then be genrically used by initializing proper pwm_info structure in the backlight setup call. Cc: cbroo...@gmail.com Cc: jani.nik...@linux.intel.com Signed-off-by: Shobhit Kumar

[Intel-gfx] [PATCH 0/3] LPSS PWM support for devices that support it

Hi, This is an untested attempt to enable LPSS PWM in the driver. As part of this did some restructuring for encapsulating the pwm_info inside the panel->backlight itself. This makes enabling LPSS PWM clean and simple. Not sending yet to pwm mailing list as this is all untested. C.B. please test

[Intel-gfx] [PATCH 2/3] pwm: lpss: Add intel-gfx as consumer device in lookup table

Cc: cbroo...@gmail.com Cc: jani.nik...@linux.intel.com Signed-off-by: Shobhit Kumar --- drivers/pwm/pwm-lpss-platform.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c index 54433fc..910bc14

[Intel-gfx] [PATCH] drm/i915: Only complain about n_edp_entries with eDP ports

From: Ville Syrjälä commit 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL") added sanity checks to make sure we don't end up with too many ddi translation values for eDP ports, but it actually failed to check if the port is eDP.

Re: [Intel-gfx] [PATCH] drm/i915: Handle PipeC fused off on HSW

On 11.01.2016 19:56, Ville Syrjälä wrote: On Mon, Dec 21, 2015 at 01:57:22PM +0200, Gabriel Feceoru wrote: On some HSW boards all pipeC tests fail with various dmesg errors. This seems to be caused by Pipe C beeing disabled in FUSE_STRAP and thus reading back the PIPECONF register is always

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on 37f6c2ae666fbba9eff4355115252b8b0fd43050 drm-intel-nightly: 2016y-01m-12d-14h-25m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) Test kms_pipe_crc_basic: Subgroup

  1   2   >