similar to: [PATCH] drm/nouveau: Fix deadlock in nv50_mstm_register_connector()

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

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 M1200 Mobile] (rev a2) Also include safe-guards to avoid NULL dereferencing of fbcon,

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:

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

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 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

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

Hi! My development VM (KVM guest, virtio graphics) is throwing warnings when I start up X while running a build from Linus' tree with lockdep turned on. I tried to bisect it, and it looks like at least the "suspicious RCU usage" one started triggering in commit 889165ad6190556ffe4a8fa6b0e486f1c25589d8 ("drm/virtio: pass gem reservation object to ttm init"). Slightly

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

On Mon, 2018-08-06 at 10:43 +0200, Daniel Vetter wrote: > On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > > I'm sure I don't need to tell you that fb_helper's locking is a mess. > > That being said; fb_helper's locking mess can seriously complicate the > > runtime suspend/resume operations of drivers because it can invoke > > atomic commits

When DP MST hubs get confused, they can occasionally stop responding for a good bit of time up until the point where the DRM driver manages to do the right DPCD accesses to get it to start responding again. In a worst case scenario however, this process can take upwards of 10+ seconds. Currently we use the default output_poll_changed handler drm_fb_helper_output_poll_changed() to handle output

When we disable hotplugging on the GPU, we need to be able to synchronize with each connector's hotplug interrupt handler before the interrupt is finally disabled. This can be a problem however, since nouveau_connector_detect() currently grabs a runtime power reference when handling connector probing. This will deadlock the runtime suspend handler like so: [ 861.480896] INFO: task

When DP MST hubs get confused, they can occasionally stop responding for a good bit of time up until the point where the DRM driver manages to do the right DPCD accesses to get it to start responding again. In a worst case scenario however, this process can take upwards of 10+ seconds. Currently we use the default output_poll_changed handler drm_fb_helper_output_poll_changed() to handle output

This is a complicated one. Essentially, there's currently a problem in the MST core that hasn't really caused any issues that we're aware of (emphasis on "that we're aware of"): locking. When we go through and probe the link addresses and path resources in a topology, we hold no locks when updating ports with said information. The members I'm referring to in

On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. > That being said; fb_helper's locking mess can seriously complicate the > runtime suspend/resume operations of drivers because it can invoke > atomic commits and connector probing from anywhere that calls >

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

On Wed, Aug 01, 2018 at 05:14:57PM -0400, Lyude Paul wrote: > When we disable hotplugging on the GPU, we need to be able to > synchronize with each connector's hotplug interrupt handler before the > interrupt is finally disabled. This can be a problem however, since > nouveau_connector_detect() currently grabs a runtime power reference > when handling connector probing. This