Re: [Intel-gfx] [PATCH] drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Chris Wilson
On Wed, Nov 02, 2016 at 05:00:28PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Use of an un-allocated bit in flags is making me nervous so I > thought to use the bit zero of the private pointer instead. > > That should be safer against the core kernel

[Intel-gfx] [PATCH 02/12] drm/i915: Defer transfer onto execution timeline to actual hw submission

2016-11-02 Thread Chris Wilson
Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto the hardware queue when the request is ready.

[Intel-gfx] [PATCH 06/12] drm/i915/scheduler: Execute requests in order of priorities

2016-11-02 Thread Chris Wilson
Track the priority of each request and use it to determine the order in which we submit requests to the hardware via execlists. The priority of the request is determined by the user (eventually via the context) but may be overridden at any time by the driver. When we set the priority of the

[Intel-gfx] [PATCH 04/12] drm/i915/scheduler: Signal the arrival of a new request

2016-11-02 Thread Chris Wilson
The start of the scheduler, add a hook into request submission for the scheduler to see the arrival of new requests and prepare its runqueues. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/i915_gem_request.c |

[Intel-gfx] [PATCH 10/12] drm/i915/scheduler: Support user-defined priorities

2016-11-02 Thread Chris Wilson
Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority

[Intel-gfx] [PATCH 01/12] drm/i915: Split request submit/execute phase into two

2016-11-02 Thread Chris Wilson
In order to support deferred scheduling, we need to differentiate between when the request is ready to run (i.e. the submit fence is signaled) and when the request is actually run (a new execute fence). This is typically split between the request itself wanting to wait upon others (for which we

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote: > CEA-861-F specs defines new 4k video modes to be used with > HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the > way till VIC=107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private URL : https://patchwork.freedesktop.org/series/14745/ State : success == Summary == Series 14745v1 drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Tidy slab cache allocations (rev2)

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915: Tidy slab cache allocations (rev2) URL : https://patchwork.freedesktop.org/series/14731/ State : warning == Summary == Series 14731v2 drm/i915: Tidy slab cache allocations https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/2/mbox/ Test

[Intel-gfx] Trivial priority scheduler

2016-11-02 Thread Chris Wilson
Now that the tree has caught up, we can now look at the next steps towards a basic scheduler. No timeslicing, no preemption, no fairness, we simply choose the highest priority request to execute next. (An incoming high priority request will bump the priority on its prerequisites so that it will

[Intel-gfx] [PATCH] drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Use of an un-allocated bit in flags is making me nervous so I thought to use the bit zero of the private pointer instead. That should be safer against the core kernel changes and safe since I can't imagine we can get a fence at the odd address.

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 10:27 PM, Ville Syrjälä wrote: On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote: CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the way till VIC=107. Our existing CEA modedb

[Intel-gfx] [RFC] drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Not sure if it matters for performance at all but it should save some wastage and enable a better insight into the usage. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson ---

[Intel-gfx] [PATCH 12/12] drm/i915: Support explicit fencing for execbuf

2016-11-02 Thread Chris Wilson
Now that the user can opt-out of implicit fencing, we need to give them back control over the fencing. We employ sync_file to wrap our drm_i915_gem_request and provide an fd that userspace can merge with other sync_file fds and pass back to the kernel to wait upon before future execution.

[Intel-gfx] [PATCH 11/12] drm/i915: Enable userspace to opt-out of implicit fencing

2016-11-02 Thread Chris Wilson
Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

2016-11-02 Thread Chris Wilson
The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only allow execution after all dependencies have been

[Intel-gfx] [PATCH 07/12] drm/i915/scheduler: Boost priorities for flips

2016-11-02 Thread Chris Wilson
Boost the priority of any rendering required to show the next pageflip as we want to avoid missing the vblank by being delayed by invisible workload. We prioritise avoiding jank and jitter in the GUI over starving background tasks. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 03/12] drm/i915: Remove engine->execlist_lock

2016-11-02 Thread Chris Wilson
The execlist_lock is now completely subsumed by the engine->timeline->lock, and so we can remove the redundant layer of locking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_gem.c | 4 ++--

[Intel-gfx] [PATCH 08/12] drm/i915/guc: Cache the client mapping

2016-11-02 Thread Chris Wilson
Use i915_gem_object_pin_map() for the guc client's lifetime to replace the peristent kmap + frequent kmap_atomic with a permanent vmapping. This avoids taking the obj->mm.lock mutex whilst inside irq context later. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 09/12] HACK drm/i915/scheduler: emulate a scheduler for guc

2016-11-02 Thread Chris Wilson
This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a simple execlist (where the CPU has to wake up

Re: [Intel-gfx] [RFC] drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Chris Wilson
On Wed, Nov 02, 2016 at 05:44:07PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Not sure if it matters for performance at all but it should > save some wastage and enable a better insight into the usage. With the caveat of avoiding the plug into the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915/sw_fence: Allocate callbacks from dedicates slab caches URL : https://patchwork.freedesktop.org/series/14750/ State : success == Summary == Series 14750v1 drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio (rev2)

2016-11-02 Thread Patchwork
== Series Details == Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio (rev2) URL : https://patchwork.freedesktop.org/series/14688/ State : warning == Summary == Series 14688v2 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915: Split request submit/execute phase into two

2016-11-02 Thread Patchwork
== Series Details == Series: series starting with [01/12] drm/i915: Split request submit/execute phase into two URL : https://patchwork.freedesktop.org/series/14751/ State : success == Summary == Series 14751v1 Series without cover letter

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

2016-11-02 Thread Pandiyan, Dhinakaran
On Tue, 2016-11-01 at 21:50 +0200, Jani Nikula wrote: > On Tue, 01 Nov 2016, "Pandiyan, Dhinakaran" > wrote: > > On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote: > >> On Tue, 01 Nov 2016, Dhinakaran Pandiyan > >> wrote: > >> >

[Intel-gfx] [PATCH v5 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

2016-11-02 Thread Dhinakaran Pandiyan
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. Let's apply this work around to GEN9 platforms too, as it

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Shashank Sharma
CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the way till VIC=107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse 4k modes using the existing techniques, we have to complete the modedb

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107) (rev3)

2016-11-02 Thread Sharma, Shashank
The failure has nothing to do with the patch, seems irrelevant. Regards Shashank -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, November 2, 2016 3:48 PM To: Sharma, Shashank Cc: intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: Unify global_list into global_link

2016-11-02 Thread Chris Wilson
On Wed, Nov 02, 2016 at 12:16:04PM +0200, Joonas Lahtinen wrote: > $ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h > > Cc: Chris Wilson > Signed-off-by: Joonas Lahtinen Ok, I keep trying to find a better name than global_*, but

[Intel-gfx] [PATCH] drm/i915: Fix pages pin counting around swizzle quirk

2016-11-02 Thread Chris Wilson
commit bc0629a76726 ("drm/i915: Track pages pinned due to swizzling quirk") fixed one problem, but revealed a whole lot more. The root cause of the pin count mismatch for the swizzle quirk (for L-shaped memory on gen3/4) was that we were incrementing the pages_pin_count upon getting the backing

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pages pin counting around swizzle quirk

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915: Fix pages pin counting around swizzle quirk URL : https://patchwork.freedesktop.org/series/14720/ State : success == Summary == Series 14720v1 drm/i915: Fix pages pin counting around swizzle quirk

[Intel-gfx] [PATCH i-g-t v5] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-02 Thread Mika Kahola
This is a testcase with multiple planes. The idea here is the following - draw a uniform frame with blue color - grab crc for reference - put planes randomly on top with the same blue color - punch holes with black color into the primary framebuffer - ideally the planes should cover these

[Intel-gfx] [PATCH] drm/i915: Unify global_list into global_link

2016-11-02 Thread Joonas Lahtinen
$ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h Cc: Chris Wilson Signed-off-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c | 10 +- drivers/gpu/drm/i915/i915_drv.h | 2 +-

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107) (rev3)

2016-11-02 Thread Patchwork
== Series Details == Series: drm: Complete CEA modedb(VIC 1-107) (rev3) URL : https://patchwork.freedesktop.org/series/14090/ State : warning == Summary == Series 14090v3 drm: Complete CEA modedb(VIC 1-107) https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/3/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify global_list into global_link

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915: Unify global_list into global_link URL : https://patchwork.freedesktop.org/series/14722/ State : warning == Summary == Series 14722v1 drm/i915: Unify global_list into global_link https://patchwork.freedesktop.org/api/1.0/series/14722/revisions/1/mbox/

[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle link training failure during modeset for DDI (rev3)

2016-11-02 Thread Patchwork
== Series Details == Series: Handle link training failure during modeset for DDI (rev3) URL : https://patchwork.freedesktop.org/series/14556/ State : failure == Summary == Series 14556v3 Handle link training failure during modeset for DDI

[Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure

2016-11-02 Thread Manasi Navare
If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH] drm/i915: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Joonas Lahtinen
Unify {use,has}_64bit_reloc into dev_priv->info. Cc: Chris Wilson Signed-off-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-

Re: [Intel-gfx] [PATCH] drm/i915: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Chris Wilson
On Wed, Nov 02, 2016 at 02:32:54PM +0200, Joonas Lahtinen wrote: > Unify {use,has}_64bit_reloc into dev_priv->info. > > Cc: Chris Wilson > Signed-off-by: Joonas Lahtinen > --- > drivers/gpu/drm/i915/i915_drv.h | 3 +++ >

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Show the execlist queue in debugfs/i915_engine_info

2016-11-02 Thread Joonas Lahtinen
On to, 2016-10-27 at 01:03 +0100, Chris Wilson wrote: > When looking at freezes whilst working on execlists, knowing the order > of the pending requests in the driver is useful. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Joonas Lahtinen
On ke, 2016-11-02 at 14:07 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We can use the preferred KMEM_CACHE helper for brevity. > > Also simplifiy error unwind by only setting the ENOMEM > error code once. You did not do this part in this patch. > >

Re: [Intel-gfx] [PATCH v2] drm/i915: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Joonas Lahtinen
On ke, 2016-11-02 at 13:25 +, Chris Wilson wrote: > On Wed, Nov 02, 2016 at 02:55:36PM +0200, Joonas Lahtinen wrote: > > > > Move has_64bit_reloc into dev_priv->info. > > ... so that it is shown in the feature list for debugging Ok, I'll add more detail. > > @@ -288,7 +288,8 @@ static

[Intel-gfx] [PATCH] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Tvrtko Ursulin
From: Tvrtko Ursulin We can use the preferred KMEM_CACHE helper for brevity. Also simplifiy error unwind by only setting the ENOMEM error code once. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 23

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 7:58 PM, Andrzej Hajda wrote: On 02.11.2016 10:46, Shashank Sharma wrote: CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the way till VIC=107. Our existing CEA modedb contains only 64 modes

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Andrzej Hajda
On 02.11.2016 15:44, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/2/2016 7:58 PM, Andrzej Hajda wrote: >> On 02.11.2016 10:46, Shashank Sharma wrote: >>> CEA-861-F specs defines new 4k video modes to be used with >>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the >>> way

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 8:44 PM, Andrzej Hajda wrote: On 02.11.2016 15:44, Sharma, Shashank wrote: Regards Shashank On 11/2/2016 7:58 PM, Andrzej Hajda wrote: On 02.11.2016 10:46, Shashank Sharma wrote: CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs.

Re: [Intel-gfx] [PATCH v2] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Joonas Lahtinen
On ke, 2016-11-02 at 15:14 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We can use the preferred KMEM_CACHE helper for brevity. > > Also simplifiy error unwind by only setting the ENOMEM > error code once. > > v2: Add forgotten changes. (Joonas Lahtinen) >

Re: [Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02 Thread Patrik Jakobsson
On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula wrote: > If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to > check for the config everywhere. > > Signed-off-by: Jani Nikula Looks good and I like the idea. Reviewed-by: Patrik

Re: [Intel-gfx] [PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl

2016-11-02 Thread sourab gupta
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote: > The minimal sampling period is now configurable via a > dev.i915.oa_min_timer_exponent sysctl parameter. > > Following the precedent set by perf, the default is the minimum that > won't (on its own) exceed the default

[Intel-gfx] [PATCH v2] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

2016-11-02 Thread Ander Conselvan de Oliveira
Hardware engineers confirmed that writing to it has no effect, as implied by the FIXME comment. v2: Also remove comment from bxt_ddi_phy_verify_state(). (Imre) Cc: Imre Deak Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Imre

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Saarinen, Jani
> == Series Details == > > Series: drm/i915/gvt: Fix workload status after wait > URL : https://patchwork.freedesktop.org/series/14711/ > State : failure > > == Summary == > > Series 14711v1 drm/i915/gvt: Fix workload status after wait >

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Zhenyu Wang
On 2016.11.02 08:47:52 +0200, Joonas Lahtinen wrote: > On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote: > > From commit e95433c73a11759203af1cae5958f998c9673370, workload status > > setting > > was changed to only capture on error path, but we need to set it properly in > > normal path too,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915/gvt: Fix workload status after wait URL : https://patchwork.freedesktop.org/series/14711/ State : failure == Summary == Series 14711v1 drm/i915/gvt: Fix workload status after wait https://patchwork.freedesktop.org/api/1.0/series/14711/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v8 03/12] drm/i915: rename OACONTROL GEN7_OACONTROL

2016-11-02 Thread sourab gupta
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote: > OACONTROL changes quite a bit for gen8, with some bits split out into a > per-context OACTXCONTROL register. Rename now before adding more gen7 OA > registers > > Signed-off-by: Robert Bragg > Reviewed-by: Matthew

[Intel-gfx] [PATCH v2] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Zhenyu Wang
From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting was changed to only capture on error path, but we need to set it properly in normal path too, otherwise we'll fail to complete workload which could lead guest VM vGPU reset. v2: uses braces and add Fixes tag. Fixes:

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Joonas Lahtinen
On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote: > From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting > was changed to only capture on error path, but we need to set it properly in > normal path too, otherwise we'll fail to complete workload which could lead > guest

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy slab cache allocations

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915: Tidy slab cache allocations URL : https://patchwork.freedesktop.org/series/14731/ State : success == Summary == Series 14731v1 drm/i915: Tidy slab cache allocations https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/1/mbox/ Test kms_flip:

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Andrzej Hajda
On 02.11.2016 10:46, Shashank Sharma wrote: > CEA-861-F specs defines new 4k video modes to be used with > HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the > way till VIC=107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to parse 4k modes using

[Intel-gfx] [PATCH v2] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Tvrtko Ursulin
From: Tvrtko Ursulin We can use the preferred KMEM_CACHE helper for brevity. Also simplifiy error unwind by only setting the ENOMEM error code once. v2: Add forgotten changes. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin Reviewed-by:

Re: [Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02 Thread Sean Paul
On Wed, Nov 2, 2016 at 2:03 AM, Patrik Jakobsson wrote: > On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula wrote: >> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to >> check for the config everywhere. >> >> Signed-off-by:

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 9:32 PM, Ville Syrjälä wrote: On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/2/2016 7:58 PM, Andrzej Hajda wrote: On 02.11.2016 10:46, Shashank Sharma wrote: CEA-861-F specs defines new 4k video modes to be used

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä
On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/2/2016 7:58 PM, Andrzej Hajda wrote: > > On 02.11.2016 10:46, Shashank Sharma wrote: > >> CEA-861-F specs defines new 4k video modes to be used with > >> HDMI 2.0 EDIDs. These modes start at

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä
On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/2/2016 9:32 PM, Ville Syrjälä wrote: > > On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 11/2/2016 7:58 PM, Andrzej Hajda

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 9:50 PM, Ville Syrjälä wrote: On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/2/2016 9:32 PM, Ville Syrjälä wrote: On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/2/2016

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Deucher, Alexander
> -Original Message- > From: Shashank Sharma [mailto:shashank.sha...@intel.com] > Sent: Wednesday, November 02, 2016 5:46 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: airl...@redhat.com; daniel.vet...@intel.com; > jose.ab...@synopsys.com; Shashank Sharma;

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote: > CEA-861-F specs defines new 4k video modes to be used with > HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the > way till VIC=107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä
On Wed, Nov 02, 2016 at 09:57:12PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/2/2016 9:50 PM, Ville Syrjälä wrote: > > On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 11/2/2016 9:32 PM, Ville Syrjälä

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank
Regards Shashank On 11/2/2016 10:04 PM, Ville Syrjälä wrote: On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote: CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the way till VIC=107. Our existing CEA modedb

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Tvrtko Ursulin
On 01/11/2016 16:41, Chris Wilson wrote: On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote: Merged to dinq, thanks for the review! Almost as bad as me in forgetting to add the r-b. dim save us! :) Took me some time to figure out what is bad in this case. :) For the reference

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Chris Wilson
On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote: > > On 01/11/2016 16:41, Chris Wilson wrote: > >On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote: > >> > >>Merged to dinq, thanks for the review! > > > >Almost as bad as me in forgetting to add the r-b. dim save us! :)

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Tvrtko Ursulin
On 02/11/2016 08:37, Chris Wilson wrote: On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote: On 01/11/2016 16:41, Chris Wilson wrote: On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote: Merged to dinq, thanks for the review! Almost as bad as me in forgetting to

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Ander Conselvan De Oliveira
On Wed, 2016-11-02 at 07:24 +, Saarinen, Jani wrote: > > > > == Series Details == > > > > Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init > > sequence (rev2) > > URL   : https://patchwork.freedesktop.org/series/14669/ > > State : warning > > > > == Summary == > > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait (rev2)

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915/gvt: Fix workload status after wait (rev2) URL : https://patchwork.freedesktop.org/series/14711/ State : failure == Summary == Series 14711v2 drm/i915/gvt: Fix workload status after wait

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Patchwork
== Series Details == Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2) URL : https://patchwork.freedesktop.org/series/14669/ State : warning == Summary == Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Saarinen, Jani
> == Series Details == > > Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init > sequence (rev2) > URL : https://patchwork.freedesktop.org/series/14669/ > State : warning > > == Summary == > > Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy > init

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

2016-11-02 Thread Maarten Lankhorst
Op 01-11-16 om 14:41 schreef Ville Syrjälä: > On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote: >> Op 01-11-16 om 14:09 schreef Ville Syrjälä: >>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote: Add for_each_(old)(new)_(plane,connector,crtc)_in_state

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

2016-11-02 Thread Joonas Lahtinen
On ti, 2016-11-01 at 15:27 +0200, Mika Kuoppala wrote: > Comparing pte index to a number of entries is wrong > when clearing a range of pte entries. Use end marker > of 'one past' to correctly point adequate number of > ptes to the scratch page. > > v2: assert early instead of warning late