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

drm/nouveau/mmu: flush tlbs before deleting page tables

2017-10-27T08:38:07+00:00

commit 77913bbcb43ac9a07a6fe849c2fd3bf85fc8bdd8 upstream.

Even though we've zeroed the PDE, the GPU may have cached the PD, so we
need to flush when deleting them.

Noticed while working on replacement MMU code, but a backport might be a
good idea, so let's fix it in the current code too.

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

drm/nouveau/bsp/g92: disable by default

2017-10-27T08:38:07+00:00

commit 194d68dd051c2dd5ac2b522ae16100e774e8d869 upstream.

G92's seem to require some additional bit of initialization before the
BSP engine can work. It feels like clocks are not set up for the
underlying VLD engine, which means that all commands submitted to the
xtensa chip end up hanging. VP seems to work fine though.

This still allows people to force-enable the bsp engine if they want to
play around with it, but makes it harder for the card to hang by
default.

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

drm/nouveau/gr/gf100-: fix ccache error logging

2017-10-21T15:21:38+00:00

[ Upstream commit 1894054dc1b6e4395048b2c0f28832a3f4320fd3 ]

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

drm/nouveau/pci/msi: disable MSI on big-endian platforms by default

2017-09-09T15:39:41+00:00

commit bc60c90f472b6e762ea96ef384072145adc8d4af upstream.

It appears that MSI does not work on either G5 PPC nor on a E5500-based
platform, where other hardware is reported to work fine with MSI.

Both tests were conducted with NV4x hardware, so perhaps other (or even
this) hardware can be made to work. It's still possible to force-enable
with config=NvMSI=1 on load.

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

drm/nouveau/bar/gf100: fix access to upper half of BAR2

2017-08-07T01:59:41+00:00

commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.

Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.

We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.

This fixes severe GPU hang/lockup issues revealed by Wayland on F26.

Shout-out to NVIDIA for the quick response with the potential cause!

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

drm/nouveau/disp/nv50-: bump max chans to 21

2017-08-07T01:59:41+00:00

commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.

GP102's cursors go from chan 17..20. Increase the array size to hold
their data properly.

Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

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