similar to: [PATCH] Accept 3d controllers and not only VGA controllers.

Sure, I can easily split it into two commits, but I would like to have an OK on the actual code changes before splitting the patch. Best regards, Josef Larsson On 2017-11-11 01:05, Tobias Klausmann wrote: > > On 11/10/17 7:49 PM, Josef Larsson wrote: >> Accept 3d controllers and not only VGA controllers. According to Ilia >> Mirkin, >> the VGA controller check should be

On 14 December 2017 at 23:45, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > On 12/3/17 8:56 PM, Josef Larsson wrote: >> >> Sure, I can easily split it into two commits, but I would like to have >> an OK on the actual code changes before splitting the patch. I'm not actually sure this is a good idea still. As I recall, part of the purpose

Without a NULL pointer safe-guard patch, I get a kernel oops when I plug in external displays in my docking station, (exactly the same issue as https://bugs.freedesktop.org/show_bug.cgi?id=101778) and without removing or modifying the check (accepting PCI_CLASS_DISPLAY_3D in the if-condition), I cannot use external displays through my docking station. This is on an optimus system where I use

On 11/10/17 7:49 PM, Josef Larsson wrote: > Accept 3d controllers and not only VGA controllers. According to Ilia > Mirkin, > the VGA controller check should be removed. This makes it possible > to use external connectors on a docking station (40A5) for a Thinkpad P51. > (See Bug 101778). > > lspci example: > > 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro

On 12/3/17 8:56 PM, Josef Larsson wrote: > Sure, I can easily split it into two commits, but I would like to have > an OK on the actual code changes before splitting the patch. > > Best regards, > > Josef Larsson > > > On 2017-11-11 01:05, Tobias Klausmann wrote: >> On 11/10/17 7:49 PM, Josef Larsson wrote: >>> Accept 3d controllers and not only VGA

On 14 December 2017 11:55:35 p.m. GMT+01:00, Ben Skeggs <skeggsb at gmail.com> wrote: >On 14 December 2017 at 23:45, Tobias Klausmann ><tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 12/3/17 8:56 PM, Josef Larsson wrote: >>> >>> Sure, I can easily split it into two commits, but I would like to >have >>> an OK on the actual code

I've discussed it with Ben and we actually found a better solution. There are just some calls inside those functions which should get NULL checks, nv50_mstm_register_connector and nv50_mstm_destroy_connector. Or at least something similiar so that the code doesn't depent on the fbcon object being there. On Mon, Dec 18, 2017 at 6:30 PM, Josef Larsson <josef.lar at gmail.com> wrote:

Currently; we're grabbing all of the modesetting locks before adding MST connectors to fbdev. This isn't actually necessary, and causes a deadlock as well: ====================================================== WARNING: possible circular locking dependency detected 4.17.0-rc3Lyude-Test+ #1 Tainted: G O ------------------------------------------------------ kworker/1:0/18 is

https://bugs.freedesktop.org/show_bug.cgi?id=101778 Bug ID: 101778 Summary: Kernel Error on Lenovo P51 when setting graphics to hybrid (Nvidia Optimus with intel+nvidia) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal

This patch set replaces the occurrences of drm_*_reference() and drm_*_unreference() with the new drm_*_get() and drm_*_put() functions. All patches in the series do the same thing, converting to the new APIs. I created patches per DRM driver as suggested by Daniel Vetter. Background: In the kernel, reference counting APIs use *_get(), *_put() style naming to reference-count the objects. But DRM

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 3ed12a8cfc91..a4a586807903 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, ret = -ENOMEM; goto

Introduce accessors for TTM buffer object memory that has been mapped into the kernel virtual address space or as IO memory. IO memory needs to be accessed via special accessor functions, not by dereferencing the iomem cookie. The wrappers hide the details of 32-bit access and honour the TTM map type. nv04_crtc_cursor_set() is changed to use the new wrappers. 'cursor' is received from

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need. The rest is

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need. The rest is

Hi all, First thing first: It works, I now no longer have a few dropped frames every 10s on my testbox here with the pageflip i-g-t tests. Random notes: - New design has per-crtc locks to protect the crtc input-side (pageflip, cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It also required completely revamped fb lifecycle management, those are now refcounted

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me know if you need more info. > > > [ 0.633617]

The base917c_format isn't exported, so make it static to avoid the following warning: drivers/gpu/drm/nouveau/dispnv50/base917c.c:26:1: warning: symbol 'base917c_format' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk> --- drivers/gpu/drm/nouveau/dispnv50/base917c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

From: Colin Ian King <colin.king at canonical.com> The check to see if mstm->msto is null is redundant because it is an array and hence can never be null. Remove the redundant check. Detected by CoverityScan, CID#1375915 ("Array compared against 0") Signed-off-by: Colin Ian King <colin.king at canonical.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 2 +- 1 file

From: Colin Ian King <colin.king at canonical.com> The null check on the array msto is incorrect since msto is never null. The null check should be instead on msto[i] since this is being dereferenced in the call to drm_mode_connector_attach_encoder. Thanks to Emil Velikov for pointing out the mistake in my original fix and for suggesting the correct fix. Detected by CoverityScan,