Pierre Moreau [Wed, 7 Dec 2016 23:57:08 +0000 (00:57 +0100)]
drm/nouveau/bl: Assign different names to interfaces
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.
v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.
v3:
* Define a macro for the size of the backlight name, to avoid defining
it multiple times;
* Use snprintf in place of sprintf.
v4:
* Do not create similarly named interfaces when reaching the maximum
amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Mon, 12 Dec 2016 07:52:45 +0000 (17:52 +1000)]
drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas
TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.
That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.
This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org [v4.8+]
Ben Skeggs [Fri, 9 Dec 2016 07:13:08 +0000 (17:13 +1000)]
drm/nouveau/fifo/gf100-: recover from host mmu faults
This has been on the TODO list for a while now, recovering from things
such as attempting to execute a push buffer or touch a semaphore in an
unmapped memory area.
The only thing required on the HW side here is that the offending
channel is removed from the runlist, and *not* a full reset of PFIFO.
This used to be a bit messier to handle before the rework to make use
of engine topology info, but is apparently now trivial.
Hans de Goede [Mon, 21 Nov 2016 16:50:55 +0000 (17:50 +0100)]
drm/nouveau: Queue hpd_work on (runtime) resume
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Hans de Goede [Mon, 21 Nov 2016 16:50:54 +0000 (17:50 +0100)]
drm/nouveau: Rename acpi_work to hpd_work
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 <hdegoede@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Mario Kleiner [Wed, 23 Nov 2016 06:58:54 +0000 (07:58 +0100)]
drm/nouveau/kms/nv50: Fix atomic pageflip events.
The new atomic modesetting/pageflip code for nv50+ for
Linux 4.10+ no longer uses pageflip irq's to signal
flip completion. Instead it polls for flip completion
from within a kthread/work queue.
This creates a race between the vblank irq handler
updating the vblank count and timestamp for the
vblank of flip completion, and the kthread's
polling code detecting flip completion and sending
out the flip completion event.
Depending on who executes a few microseconds earlier,
the flip completion event will either contain correct
count/timestamp or a stale count/timestamp from the
previous vblank. This error was observed for about
50% of all executed flips, e.g., observable under DRI2
by the Xorg.log filling with flip handler warning
messages.
Call drm_accurate_vblank_count() before sending
out flip completion events to enforce a vblank
count/ts update for the vblank of flip completion
and avoid stale counts/timestamps.
This fix leads to one redundant call to drm_update_vblank_count
for each completed flip, but no other side effects. On
a ~6 year old Core i7 M620@ 2.67GHz the redundant call
costs about 10 usecs per flip
Successfully tested on GeForce 9500/9600/330M so far.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Hans de Goede [Wed, 9 Nov 2016 17:17:44 +0000 (18:17 +0100)]
drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE
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 <hdegoede@redhat.com>
Ben Skeggs [Sat, 5 Nov 2016 04:33:14 +0000 (14:33 +1000)]
drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex
This avoids an issue that occurs when we're attempting to preempt multiple
channels simultaneously. HW seems to ignore preempt requests while it's
still processing a previous one, which, well, makes sense.
Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel
piglit runs on (at least) GM107.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
drm/nouveau/gr: fallback to legacy paths during firmware lookup
Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path
if they cannot be found in the new, "official" path. User setups were
broken by the switch, which is bad.
There are only 4 firmware files we may want to look up that way, so
hardcode them into the lookup function. All new firmware files should
use the standard "nvidia/<chip>/gr/" path.
Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
Ben Skeggs [Fri, 4 Nov 2016 07:20:36 +0000 (17:20 +1000)]
drm/nouveau/kms/nv50: transition to atomic interfaces internally
This commit implements the atomic commit interfaces, and implements the
legacy modeset and page flipping interfaces on top of them.
There's two major changes in behavior from before:
- We're now making use of interlocks between core and satellite EVO
channels, which greatly improves our ability to keep their states
synchronised.
- DPMS is now implemented as a full modeset to either tear down the
entire pipe (or bring it back up). This choice was made mostly
to ease the initial implementation, but I'm also not sure what we
gain by bring backing the old behaviour. We shall see.
This does NOT currently expose the atomic ioctl by default, due to
limited testing having been performed.
Ben Skeggs [Fri, 4 Nov 2016 07:20:36 +0000 (17:20 +1000)]
drm/nouveau/kms/nv50: ensure encoder normal power state is enabled at startup
To handle low-power DPMS states, we currently change an OR's (Output
Resource) normal (active) power state to be off, leaving the rest of
the display configured as usual.
Under atomic modesetting, we will instead be doing a full modeset to
tear down the pipe fully when entering a low-power state.
As we'll no longer be touching the OR's PWR registers during runtime
operation, we need to ensure the normal power state is set correctly
during initialisation.
Ben Skeggs [Fri, 4 Nov 2016 07:20:36 +0000 (17:20 +1000)]
drm/nouveau/kms/nv50: separate out core surface commit
This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.
The legacy interfaces have been wrapped on top of them.
As of this commit, we're no longer bothering to point the core surface
at a valid framebuffer. Prior to this, we'd initially point the core
channel to the framebuffer passed in a mode_set()/mode_set_base(), and
then use the base channel for any page-flip updates, leaving the core
channel pointing at stale information.
The important thing here is to configure the core surface parameters in
such a way that EVO's error checking is satisfied.
TL;DR: The situation isn't too much different to before.
There may be brief periods of times during modesets where the (garbage)
core surface will be showing. This issue will be resolved once support
for atomic commits has been implemented and we're able to interlock the
updates that involve multiple channels.
Ben Skeggs [Fri, 4 Nov 2016 07:20:36 +0000 (17:20 +1000)]
drm/nouveau/kms/nv50: switch mst sink back into sst mode
Sometimes we load with a sink already in MST mode. If, however, we can't
or don't want to use MST, we need to be able to switch it back to SST.
This commit instantiates a stub topology manager for any output path that
we believe (the detection of this could use some improvement) has support
for MST, and adds the connector detect() logic for detecting sink support
and switching between modes.
Ben Skeggs [Fri, 4 Nov 2016 07:20:36 +0000 (17:20 +1000)]
drm/nouveau/kms: prepare to support suspend/resume of display state with atomic
This is different from the equivilant functions in the atomic helpers in
that we fully disable the pipe instead of just setting it to inactive.
We do this (primarily) to ensure the framebuffer cleanup paths are hit,
allowing buffers to be un-pinned from memory so they can be evicted to
system memory and not lose their contents while suspended.
Ben Skeggs [Fri, 4 Nov 2016 07:20:35 +0000 (17:20 +1000)]
drm/nouveau/kms: subclass atomic connector state
This commit implements the atomic property hooks for a connector, and
wraps the legacy interface handling on top of those.
For the moment, a full modeset will be done after any property change
in order to ease subsequent changes. The optimised behaviour will be
restored for Tesla and later (earlier boards always do full modesets)
once atomic commits are implemented.
Some functions are put under the "nouveau_conn" namespace now, rather
than "nouveau_connector", to distinguish functions that will work for
(upcoming) MST connectors too.
gm20b's FB has the same capabilities as gm200, minus the ability to
allocate RAM. Create a device that reflects this instead of re-using the
gk20a device which may be incorrect.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-By: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/fb/gk20a: use regular gf100's functions
gk20a's FB is not special compared to other Kepler chips, besides the
fact it does not have VRAM. Use the regular gf100 hooks instead of the
incomplete versions we rewrote.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-By: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The gf100 constructor should be called, otherwise we will allocate a
smaller object than expected. This was without effect so far because
gk20a did not allocate a page, but with gf100's page allocation moved
to the oneinit() hook this problem has become apparent.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lucas Stach [Wed, 26 Oct 2016 11:11:06 +0000 (13:11 +0200)]
drm/nouveau: fix notify data leak
There is no reason to not free the notify data if the NTFY_DEL ioctl
failed. As nvif_notify_fini() is also called from the cleanup path of
nvif_notify_init(), the notifier may not have been successfully created
at that point. But it should also be the right thing to just free the
data in the regular fini calls, as there is nothing much we can do if
the ioctl fails, so better not leak memory.
Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Arnd Bergmann [Mon, 24 Oct 2016 15:30:38 +0000 (17:30 +0200)]
drm/nouveau: hide gcc-4.9 -Wmaybe-uninitialized
gcc-4.9 notices that the validate_init() function returns unintialized
data when called with a zero 'nr_buffers' argument, when called with the
-Wmaybe-uninitialized flag:
drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’:
drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
However, the only caller of this function always passes a nonzero
argument, and gcc-6 is clever enough to take this into account and
not warn about it any more.
Adding an explicit initialization to -EINVAL here is correct even if
the caller changed, and it avoids the warning on gcc-4.9 as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-By: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Baoyou Xie [Mon, 24 Oct 2016 03:09:03 +0000 (11:09 +0800)]
drm/nouveau: mark symbols static where possible
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes]
....
In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
projects / linux-beck.git / log