Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

Hi, On Wed, Feb 10, 2016 at 09:41:38AM +0100, Lukas Wunner wrote: > On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (arm > > multi_v7_defconfig) failed like this: >

Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation

Hi Chris, On Fri, Feb 05, 2016 at 11:09:27AM +, Chris Wilson wrote: > On Fri, Feb 05, 2016 at 01:27:10AM +0100, Lukas Wunner wrote: > > On Thu, Feb 04, 2016 at 09:21:17AM +, Li, Weinan Z wrote: > > > We still need this patch. Seems 54632abe8ca3 ("drm/i915: Fix oops

Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation

ll_changed(), not sure if these are racy as well. At least the stack traces posted by Li Weinan and Gustav Fägerlind only indicate that lastclose is racy. Best regards, Lukas > From: Li, Weinan Z > Sent: Thursday, February 04, 2016 10:34 AM > To: 'gustav.fagerl...@gmail.com'; Lukas Wunner

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

Hi, On Thu, Feb 04, 2016 at 03:00:11PM +0530, ankitprasad.r.sha...@intel.com wrote: > 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

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

Hi, On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote: > On Thu, Feb 04, 2016 at 04:46:55PM +0100, Lukas Wunner wrote: > > > + /* If the stolen region can be modified behind our backs upon suspend, > > > + * then we cannot use it to store nonvolatile co

Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation

Hi, On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote: > If the initialisation fails, we may be left with a dangling pointer with > an incomplete fbdev structure. This shouldn't happen with 4.5, the fbdev is now clobbered if initialization fails, the existing "if (dev_priv->fbdev)"

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

Hi Dave, On Tue, Feb 02, 2016 at 11:10:19AM +1000, Dave Airlie wrote: > On 2 February 2016 at 08:49, Lukas Wunner <lu...@wunner.de> wrote: > > On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > >> Enable GPU switching on the pre-retina MacBo

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

Hi, On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. This series hasn't seen any reviews or acks unfortunately. Any takers? Merging this would allow fdo #61115 to be closed (currently assigned to intel-

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

Hi Rafael, On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote: > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote: > > Hi, > > > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote: > > > On Monday, January 18, 2016

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

Hi, On Mon, Jan 18, 2016 at 03:57:29PM +0100, Rafael J. Wysocki wrote: > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote: > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote: > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sha...@intel.com > > > wrote: >

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

Hi, On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote: > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote: > > Hi, > > > > On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote: > > > On Monday, January 18, 2016 03:57

Re: [Intel-gfx] [PATCH] drm/i915: Splitting intel_dp_check_link_status

Hi, On Mon, Jan 18, 2016 at 04:22:19PM +0530, Shubhangi Shrivastava wrote: > When created originally intel_dp_check_link_status() > was supposed to handle only link training for short > pulse but has grown into handler for short pulse itself. > This patch cleans up this function by splitting it

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

Hi, On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote: > On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote: > > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote: > > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote: > > > > On Thursday,

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

2015-December/097025.html Thanks, Lukas Lukas Wunner (12): vga_switcheroo: Add handler flags infrastructure vga_switcheroo: Add support for switching only the DDC apple-gmux: Track switch state apple-gmux: Add switch_ddc support drm/edid: Switch DDC when reading the EDID drm/i915: Switch

Re: [Intel-gfx] [PATCH v2 0/6] drm/i915: start hiding away vbt structure from the driver

Hi, On Mon, Jan 11, 2016 at 09:54:36PM +0200, Jani Nikula wrote: > Hi all, first real patches since the RFC at [1]. > > The VBT is a monster and it keeps growing. Originally we've extracted > bits and pieces out of there, and added them cleanly to our own > structures in dev_priv->vbt, with our

[Intel-gfx] [PATCH v5 06/12] drm/i915: Switch DDC when reading the EDID

eedesktop.org/show_bug.cgi?id=61115 Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/intel_lvds.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-

[Intel-gfx] [PATCH v5 10/12] drm/i915: Defer probe if gmux is present but its driver isn't

=61115 Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/i915_drv.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Check DP no aux transaction bit on link training

Hi Mika, On Mon, Dec 21, 2015 at 01:39:15PM +0200, Mika Kahola wrote: > Check if no AUX transactions are required on DP link training. > If this bit is set, we can reuse the known good drive current > and pre-emphasis level from the last "full" link training. > > Bugzilla:

[Intel-gfx] [PATCH] drm/i915: Remove obsolete code from intelfb_alloc()

niel Vetter <daniel.vet...@ffwll.ch> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/intel_fbdev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

Hi, I wouldn't normally nitpick like this but since I was reading it anyway and you were asking for "OCD doc style thing". :-) This is a proofread of the force-pushed v2 in drm-intel-nightly (9a8730ddfe1d). > + > +Style Guidelines > + > + For consistency this documentation use

Re: [Intel-gfx] [PATCH v9 1/3] drm/kms_helper: Add a common place to call init and exit functions.

Hi Rafael, On Thu, Dec 03, 2015 at 02:54:00PM -0800, Rafael Antognolli wrote: > The module_init and module_exit functions will start here, and call the > subsequent init's and exit's. > > Signed-off-by: Rafael Antognolli > --- > drivers/gpu/drm/Makefile

Re: [Intel-gfx] [PATCH v9 3/3] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

Hi Rafael, On Thu, Dec 03, 2015 at 02:54:02PM -0800, Rafael Antognolli wrote: > So far, the i915 driver and some other drivers set it to the drm_device, > which doesn't allow one to know which DP a given aux channel is related > to. Changing this to be the drm_connector provides proper nesting,

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

@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > Cc: Lukas Wunner <lu...@wunner.de> > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/i915/intel_fbdev.c | 20 +--- > 1 file change

Re: [Intel-gfx] Possible i915 regression with 4.4-rc

Hi, On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote: > On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote: > > On Thu, 03 Dec 2015 21:33:29 +0100, > > Ville Syrjälä wrote: > > > > > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote: > > > > Hi, > > > > > > >

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

Hi Chris, On Fri, Nov 20, 2015 at 04:29:52PM +, Chris Wilson wrote: > 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 in > the GGTT for

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails

Hi again, On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote: > On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote: > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > > @@ -408,7 +408,10 @@ static void intel_c

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails

Hi Chris, On Thu, Nov 19, 2015 at 09:46:34PM +, Chris Wilson wrote: > On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote: > > On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote: > > > @@ -727,7 +730,8 @@ void intel_fbdev_fini(stru

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Fix oops caused by fbdev initialization failure

Hi, On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote: > On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote: > > intelfb_create() is called once on driver initialization. If it fails, > > ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may b

[Intel-gfx] [PATCH v3 0/2] fbdev fixes

ble to solve it by spliting intel_fbdev_fini() in two parts as suggested by Ville, however I think using current_is_async() is preferrable as it's simpler and less code. Browsable on GitHub: https://github.com/l1k/linux/commits/intel_fbdev_fixes Best regards, Lukas Lukas Wunner (2): drm/i91

[Intel-gfx] [PATCH 0/1] async: export current_is_async()

Hi Tejun, when you introduced current_is_async() with 84b233adcca3, was it a deliberate decision not to export it? All other non-static functions in async.c are exported as well. I'm asking because I would like to use it in i915.ko. Thanks, Lukas Lukas Wunner (1): async: export

[Intel-gfx] [PATCH 1/1] async: export current_is_async()

Introduced by 84b233adcca3 ("workqueue: implement current_is_async()"). Cc: Tejun Heo <t...@kernel.org> Signed-off-by: Lukas Wunner <lu...@wunner.de> --- kernel/async.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/async.c b/kernel/async.c index 4c3773c..d2edd

[Intel-gfx] [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails

bdev.c), call async_synchronize_full() conditionally instead of moving it into i915_driver_unload(). Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/intel_fbdev.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails

Hi, On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote: > On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote: > > Currently if intelfb_create() errors out, it unrefs the bo even though > > the fb now owns that reference. (Spotted by Ville Syrjälä.) We should &

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

Hi Ander, On Fri, Nov 13, 2015 at 05:05:09PM +0200, Ander Conselvan de Oliveira wrote: > Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify > a command to be run after a patch is applied. Use eval so enviroment > variables can be overriden with the option. For example: > >

Re: [Intel-gfx] [PATCH v7 0/3] fbdev fixes (reviewed)

Hi Jani, On Mon, Nov 09, 2015 at 04:23:34PM +0200, Jani Nikula wrote: > On Sat, 07 Nov 2015, Lukas Wunner <lu...@wunner.de> wrote: > > three patches with fbdev deadlock & failure path fixes, > > each with Reviewed-by tag by Ville or Daniel, the third one > &

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c

Hi Ville, On Mon, Nov 09, 2015 at 01:00:50PM +0200, Ville Syrjälä wrote: > On Sun, Nov 08, 2015 at 05:44:37PM +0100, Lukas Wunner wrote: > > Hi Ville, > > > > On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com > > wrote: > >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c

Hi Ville, On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Reading the driver load/unload code leaves one confused as there's > an async_schedule() in the load, but not async_synchronize_full() > in sight. In

[Intel-gfx] [PATCH v2 1/2] drm/i915: Fix oops caused by fbdev initialization failure

bdev was destroyed with intel_fbdev_fini(), the driver will oops on mst hotplug events. Fix it. Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/i915_debugfs.c | 24 +--- drivers/gpu/drm/i915/intel_dp_mst.c | 10 -- drivers/gpu/drm/i915/intel_fb

[Intel-gfx] [PATCH v2 0/2] fbdev fixes (need review)

estore_mode(). The patches are also browsable on GitHub: https://github.com/l1k/linux/commits/intel_fbdev_fixes Best regards, Lukas Lukas Wunner (2): drm/i915: Fix oops caused by fbdev initialization failure drm/i915: Tear down fbdev if initialization fails drivers/gpu/d

[Intel-gfx] [PATCH v2 2/2] drm/i915: Tear down fbdev if initialization fails

r_unreference() (if fb was not inherited from BIOS), call intel_fbdev_fini(). Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/i915_dma.c| 1 + drivers/gpu/drm/i915/intel_fbdev.c | 9 + 2 files changed, 6 i

[Intel-gfx] [PATCH v7 0/3] fbdev fixes (reviewed)

er.1445771693.git.lu...@wunner.de>) contained a 4th patch, a new version of which I'll submit separately. Thanks, Lukas Lukas Wunner (2): drm/i915: On fb alloc failure, unref gem object where it gets refed drm/i915: Fix double unref in intelfb_alloc failure path Tvrtko Ursulin (1):

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

a few times, which is racy. We should instead track the vma directly, but oh well we don't."] v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v5: * Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message. (

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

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ä <ville.syrj...@linux.intel.com> Signed-off-by: Lukas Wunner <lu...@wunner.de&

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

gt; [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown <will...@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Brun

[Intel-gfx] [PATCH] drm/i915: Clean up LVDS register handling harder

nux.intel.com> Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/intel_lvds.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 7f39b8a..baf72c1 100644 --- a/drivers/gpu

[Intel-gfx] [PATCH] drm: Remove unused fbdev_list members

n i915, nouveau and radeon. Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl, virtio and mgag200. Already removed from the latter with cc59487a05b1 ("drm/mgag200: 'fbdev_list' in 'struct mga_fbdev' is not used"). Remove it from the others. Signed-off-by: Lukas Wunner <lu...@wun

Re: [Intel-gfx] [PATCH 32/43] drm/i915: Clean up LVDS register handling

Hi Ville, On Fri, Sep 18, 2015 at 08:03:45PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Keep single 'lvds_reg' and 'lvds' variable around in > intel_lvds_init(), and read it just once at the start. Hm, is it intentional that you didn't

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

to free the memory occupied by the fb and disable the crtc; the fbcon will be unusable anyway at this point and if X11 is able to start up without errors, it should be able to reinitialize the crtc.) Browsable on GitHub: https://github.com/l1k/linux/commits/intel_fbdev_fixes Lukas Wunner (3

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

gt; [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown <will...@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Brun

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

MA we setup for the fbdev which requires the lock."] v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v5: * Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message. (Jani Nicula) v6: *

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

we should try to get it right. Signed-off-by: Lukas Wunner <lu...@wunner.de> --- drivers/gpu/drm/i915/intel_fbdev.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 12597b5..b8c11

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

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

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

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ä <ville.syrj...@linux.intel.com> Signed-off-by: Lukas Wunner <lu...@wunner.de>

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

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

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Fix failure paths around initial fbdev allocation

Hi Ville, On Thu, Oct 15, 2015 at 08:34:23PM +0300, Ville Syrjälä wrote: > On Thu, Oct 15, 2015 at 07:14:35PM +0200, Lukas Wunner wrote: > > Hi Ville, > > > > On Tue, Oct 13, 2015 at 06:04:40PM +0300, Ville Syrjälä wrote: > > > On Tue, Jun 30, 2015 at 10:06:

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Fix failure paths around initial fbdev allocation

Hi Ville, On Tue, Oct 13, 2015 at 06:04:40PM +0300, Ville Syrjälä wrote: > On Tue, Jun 30, 2015 at 10:06:27AM +0100, Lukas Wunner wrote: > > From: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > > > > We had two failure modes here: > > > > 1. > >

[Intel-gfx] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

and locks. (Suggested by Daniel Vetter.) Thanks a lot to the reviewers and testers for your valuable feedback. Lukas Wunner (6): vga_switcheroo: Add support for switching only the DDC apple-gmux: Add switch_ddc support drm/edid: Switch DDC when reading the EDID drm/i915: Switch DDC when

Re: [Intel-gfx] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

Hi, I've also pushed this series to GitHub now to ease reviewing: https://github.com/l1k/linux/commits/mbp_switcheroo_v3 Thanks, Lukas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/6] drm/i915: Switch DDC when reading the EDID

w_bug.cgi?id=61115 Tested-by: William Brown <will...@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Signed-off-by: Lukas Wunner <lu...@wun

Re: [Intel-gfx] [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

Hi Evan, On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote: > On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner <lu...@wunner.de> wrote: > > I've also pushed this series to GitHub now to ease reviewing: > > https://github.com/l1k/linux/commits/mbp_switcheroo_v3 > >

Re: [Intel-gfx] [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

Hi Evan, On Mon, Oct 05, 2015 at 11:23:21AM -0400, Evan Foss wrote: > $ dmesg|grep Apple > [0.00] efi: EFI v1.10 by Apple > [0.00] DMI: Apple Inc. MacBookPro9,1/Mac- > 4B7AC7E43945597E, > BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012 That was the last of the pre-retinas. I have

Re: [Intel-gfx] [PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.

Hi Rafael, On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote: > This is useful to determine which connector owns this AUX channel. WTF? I posted a patch in August which does exactly that: http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html Can also be pulled

Re: [Intel-gfx] [PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.

Hi Daniel, On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote: > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote: > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote: > > > This is useful to determine which connector owns this AUX channe

Re: [Intel-gfx] [PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array

Hi, On Sun, Sep 13, 2015 at 02:36:47PM -0600, Jonathan Corbet wrote: > On Mon, 7 Sep 2015 17:01:59 -0300 > Danilo Cesar Lemes de Paula wrote: > > The "highlight" code is very sensible to the order of the hash keys, > > but the order of the keys cannot be predicted.

Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

Hi Jani, On Mon, Aug 31, 2015 at 10:15:07PM +0300, Jani Nikula wrote: > On Sat, 29 Aug 2015, Lukas Wunner <lu...@wunner.de> wrote: > > the patch set I've posted August 12 included 3 commits which fix bugs > > in i915. These bugs should be fixed independently of MacBook

[Intel-gfx] [PATCH v5 1/2] drm/i915: Fix failure paths around initial fbdev allocation

ailure path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v3: * On fb alloc failure, unref gem object where it gets

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

illiam Brown <will...@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner <lu...@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer <br...@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

Hi Egbert, On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote: > drm_kms_helper_poll_enable() was converted to lock the mode_config > mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f > ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable"). > > This disregarded the

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

Hi Egbert, On Wed, Sep 02, 2015 at 12:10:19AM +0200, Egbert Eich wrote: > Lukas Wunner writes: > > On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote: > > > drm_kms_helper_poll_enable() was converted to lock the mode_config >

Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

Hi Daniel, Hi Jani, the patch set I've posted August 12 included 3 commits which fix bugs in i915. These bugs should be fixed independently of MacBook Pro GPU switching, please consider merging them: drm/i915: Preserve SSC earlier http://patchwork.freedesktop.org/patch/56921/ drm/i915: Fix

Re: [Intel-gfx] [PATCH v4 04/11] drm/i915: LVDS pixel clock check

Hi Mika, On Fri, Aug 14, 2015 at 01:03:24PM +0300, Mika Kahola wrote: It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we

Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

Hi Daniel, On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote: * Reprobing if the inactive GPU initializes before the apple-gmux module: v1 used Matthew Garrett's approach of adding a driver callback. v2 simply generates a hotplug event instead. nouveau polls its outputs

[Intel-gfx] [PATCH v2 14/22 RESEND] drm/i915: Fix failure paths around initial fbdev allocation

path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v3: * On fb alloc failure, unref gem object where it gets refed, fix

[Intel-gfx] [PATCH v2 13/22] drm/i915: Reprobe eDP and LVDS connectors on hotplug event

GT216 pre-retina] Tested-by: William Brown will...@blackhats.net.au [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner lu...@wunner.de [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer br...@bierbaumer.net [MBP 11,3 2013 intel HSW

[Intel-gfx] [PATCH v2 12/22] drm/i915: Preserve SSC earlier

turks pre-retina] Tested-by: Lukas Wunner lu...@wunner.de [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer br...@bierbaumer.net [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] Fixes: 92122789b2d6 (drm/i915: preserve SSC

[Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

on the following hardware (thanks a lot everyone!): Tested-by: Paul Hordiienko pvt.g...@gmail.com [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown will...@blackhats.net.au [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner lu...@wunner.de

[Intel-gfx] [PATCH v2 15/22 RESEND] drm/i915: On fb alloc failure, unref gem object where it gets refed

will...@blackhats.net.au [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner lu...@wunner.de [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer br...@bierbaumer.net [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work

Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false

Hi, On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote: We follow the VBT as to whether a DDI port is used for eDP and if so, do not attach a HDMI encoder to it. However there are machines for which the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link. Furthermore,

Re: [Intel-gfx] Help needed for unusual hack

Hi, On Fri, Jul 31, 2015 at 02:34:06PM +0100, harrykipper wrote: Hello, I have a Thinkpad X230 (IvyBridge, HD4000) with a very clever display mod (described to some extent by a guy here -- http://boweihe.me/?p=1442). Practically the low res native LVDS panel of the laptop was replaced with a

Re: [Intel-gfx] Help needed for unusual hack

Hi, On Sat, Aug 01, 2015 at 08:49:55PM +0100, harrykipper wrote: On Sat, 1 Aug, 2015 at 4:01 PM, Lukas Wunner lu...@wunner.de wrote: Change is_edp() to something like: -return intel_dig_port-base.type == INTEL_OUTPUT_EDP; +return intel_dig_port-base.type == INTEL_OUTPUT_EDP

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed

Hi Daniel, On Mon, Jul 06, 2015 at 09:41:51AM +0200, Daniel Vetter wrote: Please keep a record of the changes you do to the patch so I know what to look out for. Just reving the patch revision alone doesn't add much information for reviewers/maintainers. There's a changelog in the first patch

[Intel-gfx] [PATCH v4 1/2] drm/i915: Fix failure paths around initial fbdev allocation

path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v3: * On fb alloc failure, unref gem object where it gets refed, fix

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

. Signed-off-by: Lukas Wunner lu...@wunner.de Fixes: a8bb6818270c (drm/i915: Fix error path leak in fbdev fb allocation) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Ville Syrjälä ville.syrj...@linux.intel.com Cc: Daniel Vetter dan...@ffwll.ch --- drivers

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed

Hi Chris, thank you for the quick response (on a weekend no less). On Sat, Jul 04, 2015 at 01:31:48PM +0100, Chris Wilson wrote: - return intel_framebuffer_create(dev, mode_cmd, obj); + fb = intel_framebuffer_create(dev, mode_cmd, obj); + if (IS_ERR(fb)) +

[Intel-gfx] [PATCH v3 1/2] drm/i915: Fix failure paths around initial fbdev allocation

path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v3: * On fb alloc failure, unref gem object where it gets refed, fix

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

. Signed-off-by: Lukas Wunner lu...@wunner.de Fixes: a8bb6818270c (drm/i915: Fix error path leak in fbdev fb allocation) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 21

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

Hi, On Thu, Jul 02, 2015 at 02:59:24PM +0100, Tvrtko Ursulin wrote: On 07/02/2015 02:37 PM, Ville Syrjälä wrote: On Tue, Jun 30, 2015 at 10:06:27AM +0100, Tvrtko Ursulin wrote: Ville, you suggested some changes earlier; I suggest removing the unref from __intel_framebuffer_create(). Do

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

commit msg to 72 chars. (Lukas Wunner) * Added third failure mode. (Lukas Wunner) Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Fixes: 60a5ca015ffd2aacfe5674b5a401cd2a37159e07 Reported-By: Lukas Wunner lu...@wunner.de Tested-By: Lukas Wunner lu...@wunner.de Cc: Chris Wilson ch

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

...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com Fixes: 60a5ca015ffd2aacfe5674b5a401cd2a37159e07 Reported-By: Lukas Wunner lu...@wunner.de --- drivers/gpu/drm/i915/intel_fbdev.c | 21 + 1 file changed, 13 insertions(+), 8

Re: [Intel-gfx] Deadlock in intel_user_framebuffer_destroy()

Hi Jani, On Mon, Jun 29, 2015 at 02:24:19PM +0300, Jani Nikula wrote: On Mon, 15 Jun 2015, Chris Wilson ch...@chris-wilson.co.uk wrote: There wasn't, I just rewrote it incorrectly. There's also a drm_framebuffer_remove() called by intelfb_alloc which needs to be moved out of the mutex. A

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

Hi Tvrtko, On Mon, Jun 29, 2015 at 04:15:08PM +0100, Tvrtko Ursulin wrote: On 06/29/2015 03:39 PM, Lukas Wunner wrote: On Mon, Jun 15, 2015 at 11:49:52AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin tvrtko.ursu...@intel.com We had two failure modes here: 1. Deadlock

Re: [Intel-gfx] Deadlock in intel_user_framebuffer_destroy()

6871930e1d0f3d8dcb702bbb4f9b121d48a334ca.1434188640.git.lu...@wunner.de a6d60e1981004ba1e8dc4ce37b78657b2edf61c8.1434188640.git.lu...@wunner.de 77dc50305ee6fa2db076907496e373cc237e4901.1434188640.git.lu...@wunner.de From: Lukas Wunner lu...@wunner.de Date: Wed, 3 Jun 2015 14:57:41

[Intel-gfx] Deadlock in intel_user_framebuffer_destroy()

Hi, a deadlock was introduced by commit 60a5ca015ffd2aacfe5674b5a401cd2a37159e07 Author: Ville Syrjälä ville.syrj...@linux.intel.com Date: Fri Jun 13 11:10:53 2014 +0300 drm/i915: Add locking around framebuffer_references-- The commit amended

[Intel-gfx] [PATCH v4 2/2] drm/i915: Add missing MacBook Pro models with dual channel LVDS

Single channel LVDS maxes out at 112 MHz. The 15 pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Signed-off-by: Lukas Wunner lu...@wunner.de

[Intel-gfx] [PATCH v4 1/2] drm/i915: Assume dual channel LVDS if pixel clock necessitates it

) as a BTO option. v2: Avoid hardcoding 17 models by assuming dual channel LVDS if the resolution necessitates it, suggested by Jani Nikula. v3: Fix typo, thanks Joonas Lahtinen. v4: Split commit in two, suggested by Ville Syrjälä. Signed-off-by: Lukas Wunner lu...@wunner.de Tested-by: Lukas

Re: [Intel-gfx] [PATCH v3] drm/i915: Add missing MacBook Pro models with dual channel LVDS

Hi Ville, I would suggest splitting that into a separate patch. Otherwise it's going to harder to revert either change separately, should the need arise. So that part is Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Okay, commit split in two as requested. Question: Daniel Vetter

Re: [Intel-gfx] [PATCH v3] drm/i915: Add missing MacBook Pro models with dual channel LVDS

have fit into a single channel. v2: Assume dual channel LVDS if the pixel clock necessitates it, eliminating the need to hardcode 17 models, suggested by Jani Nikula. v3: Fix typo, thanks Joonas Lahtinen. Signed-off-by: Lukas Wunner lu...@wunner.de Tested-by: Lukas Wunner lu...@wunner.de Acked

[Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS

have fit into a single channel. Signed-off-by: Lukas Wunner lu...@wunner.de Tested-by: Lukas Wunner lu...@wunner.de --- drivers/gpu/drm/i915/intel_lvds.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers

Re: [Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS

Hi Jani, I think this begs the question, why don't we assume dual link lvds when we know the native mode of the panel necessitates it? Yes that's a great idea, that way we can avoid hardcoding the 17 models. Coming up in a separate e-mail is a new version of the patch. Single channel LVDS

[Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS

for MacBookPro8,2 / 8,3: https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011) Reference for MacBookPro6,2: https://bbs.archlinux.org/viewtopic.php?id=185770 Signed-off-by: Lukas Wunner lu...@wunner.de --- drivers/gpu/drm/i915/intel_lvds.c | 34 +- 1 file

<    1   2   3   >