[Intel-gfx] [PATCH v6 0/4] fbdev deadlock & failure path fixes

2015-10-25 Thread Lukas Wunner
Next iteration of these fixes, taking into account the additional issues discovered in the recent exchange with Ville (this series is in-reply-to that thread): * Patch 1 now with Reviewed-by tag by Ville (thanks!), moved to the front of the series. * Patch 2 is new, fixes a double unref of the

[Intel-gfx] [PATCH v6 1/4] drm/i915: On fb alloc failure, unref gem object where it gets refed

2015-10-25 Thread Lukas Wunner
Currently when allocating a framebuffer fails, the gem object gets unrefed at the bottom of the call stack in __intel_framebuffer_create, not where it gets refed, which is in intel_framebuffer_create_for_mode (via i915_gem_alloc_object) and in intel_user_framebuffer_create (via drm_gem_object_looku

[Intel-gfx] [PATCH v6 2/4] drm/i915: Fix double unref in intelfb_alloc failure path

2015-10-25 Thread Lukas Wunner
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails, the bo is unrefed twice: By drm_framebuffer_remove() and once more by drm_gem_object_unreference(). Fix it. Reported-by: Ville Syrjälä Signed-off-by: Lukas Wunner --- drivers/gpu/drm/i915/intel_fbdev.c | 5 ++--- 1 file chan

[Intel-gfx] [PATCH v6 3/4] drm/i915: Fix failure paths around initial fbdev allocation

2015-10-25 Thread Lukas Wunner
From: Tvrtko Ursulin We had two failure modes here: 1. Deadlock in intelfb_alloc failure path where it calls drm_framebuffer_remove, which grabs the struct mutex and intelfb_create (caller of intelfb_alloc) was already holding it. 2. Deadlock in intelfb_create failure path where it calls drm_fr

[Intel-gfx] [PATCH v6 4/4] drm/i915: Fix error handling in intelfb_create

2015-10-25 Thread Lukas Wunner
intelfb_create() is called once on driver initialization. It either uses the fb inherited from BIOS or allocates a new one by calling intelfb_alloc(). Afterwards, it calls two functions which can fail: - drm_fb_helper_alloc_fbi() can fail with -ENOMEM. - ioremap_wc() can fail on alignment issues e

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

2015-10-25 Thread Lukas Wunner
Hi, On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote: > From: Chris Wilson > > A long time ago (before 3.14) we relied on a permanent pinning of the > ifbdev to lock the fb in place inside the GGTT. However, the > introduction of stealing the BIOS framebuffer and reusing its address i

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

2015-10-25 Thread Lukas Wunner
Another observation that occurred to me only after sending away my previous message (sorry): On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote: > From: Chris Wilson > > A long time ago (before 3.14) we relied on a permanent pinning of the > ifbdev to lock the fb in place inside the GGT

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

2015-10-25 Thread Thulasimani, Sivakumar
On 10/23/2015 5:37 PM, R, Durgadoss wrote: -Original Message- From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] Sent: Wednesday, October 21, 2015 9:08 PM To: R, Durgadoss; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [RFCv2 DP-typeC 5/6] drm/i915/dp: Enable Upf

Re: [Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities

2015-10-25 Thread Sharma, Shashank
Thanks Daniel, Rob, for providing the clarification. Jim, Does this sound good to you, now ? Regards Shashank -Original Message- From: Bradford, Robert Sent: Thursday, October 22, 2015 5:36 PM To: Bish, Jim; Sharma, Shashank Cc: Palleti, Avinash Reddy; kausalmall...@gmail.com; intel-gf