linux-toradex.git/drivers/gpu/drm/nouveau, branch v4.9.34

drm/nouveau: Fix drm poll_helper handling

2017-06-17T04:41:54+00:00

[ Upstream commit 9a2eba337cacefc95b97c2726e3efdd435b3460e ]

Commit cae9ff036eea effectively disabled the drm poll_helper by checking
the wrong flag to see if the driver should enable the poll or not:
mode_config.poll_enabled is only set to true by poll_init and it is not
indicating if the poll is enabled or not.
nouveau_display_create() will initialize the poll and going to disable it
right away. After poll_init() the mode_config.poll_enabled will be true,
but the poll itself is disabled.

To avoid the race caused by calling the poll_enable() from different paths,
this patch will enable the poll from one place, in the
nouveau_display_hpd_work().

In case the pm_runtime is disabled we will enable the poll in
nouveau_drm_load() once.

Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Lyude 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Don't enabling polling twice on runtime resume

2017-06-17T04:41:54+00:00

[ Upstream commit cae9ff036eea577856d5b12860b4c79c5e71db4a ]

As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Handle fbcon suspend/resume in seperate worker

2017-06-17T04:41:54+00:00

[ Upstream commit 15266ae38fe09dae07bd8812cb7a7717b1e1d992 ]

Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

[airlied: use READ_ONCE to address Hans's comment]

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Rename acpi_work to hpd_work

2017-06-17T04:41:54+00:00

[ Upstream commit 81280d0e24e76c35f40f997af26c779bcb10b04d ]

We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops. For runtime-resume
(which gets called on resume from normal suspend too) we must call
drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock.

Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI
blocks to make it suitable for generic work.

Signed-off-by: Hans de Goede 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE

2017-06-17T04:41:54+00:00

[ Upstream commit 3a6536c51d5db3adf58dcd466a3aee6233b58544 ]

Various notebooks with nvidia GPUs generate an ACPI_VIDEO_NOTIFY_PROBE
acpi-video event when an external device gets plugged in (and again on
modesets on that connector), the default behavior in the acpi-video
driver for this is to send a KEY_SWITCHVIDEOMODE evdev event, which
causes e.g. gnome-settings-daemon to ask us to rescan the connectors
(good), but also causes g-s-d to switch to mirror mode on a newly plugged
monitor rather then using the monitor to extend the desktop (bad)
as KEY_SWITCHVIDEOMODE is supposed to switch between extend the desktop
vs mirror mode.

More troublesome are the repeated ACPI_VIDEO_NOTIFY_PROBE events on
changing the mode on the connector, which cause g-s-d to switch
between mirror/extend mode, which causes a new ACPI_VIDEO_NOTIFY_PROBE
event and we end up with an endless loop.

This commit fixes this by adding an acpi notifier block handler to
nouveau_display.c to intercept ACPI_VIDEO_NOTIFY_PROBE and:

1) Wake-up runtime suspended GPUs and call drm_helper_hpd_irq_event()
   on them, this is necessary in some cases for the GPU to detect connector
   hotplug events while runtime suspended
2) Return NOTIFY_BAD to stop acpi-video from emitting a bogus
   KEY_SWITCHVIDEOMODE key-press event

There already is another acpi notifier block handler registered in
drivers/gpu/drm/nouveau/nvkm/engine/device/acpi.c, but that is not
suitable since that one gets unregistered on runtime suspend, and
we also want to intercept ACPI_VIDEO_NOTIFY_PROBE when runtime suspended.

Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers

2017-06-17T04:41:52+00:00

[ Upstream commit 96692b097ba76d0c637ae8af47b29c73da33c9d0 ]

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: prevent userspace from deleting client object

2017-06-17T04:41:52+00:00

[ Upstream commit c966b6279f610a24ac1d42dcbe30e10fa61220b2 ]

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/tmr: fully separate alarm execution/pending lists

2017-06-14T13:06:04+00:00

commit b4e382ca7586a63b6c1e5221ce0863ff867c2df6 upstream.

Reusing the list_head for both is a bad idea.  Callback execution is done
with the lock dropped so that alarms can be rescheduled from the callback,
which means that with some unfortunate timing, lists can get corrupted.

The execution list should not require its own locking, the single function
that uses it can only be called from a single context.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/tmr: handle races with hw when updating the next alarm time

2017-05-25T13:44:36+00:00

commit 1b0f84380b10ee97f7d2dd191294de9017e94d1d upstream.

If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.

Fix this by checking again after we update HW.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/tmr: avoid processing completed alarms when adding a new one

2017-05-25T13:44:36+00:00

commit 330bdf62fe6a6c5b99a647f7bf7157107c9348b3 upstream.

The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm.  This was lazy and bad, as it leads to loads of fun
races between inter-related callers (ie. therm).

Turns out, it's not so difficult after all.  Go figure ;)

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman