Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GP102/GP104 make life difficult by redefining the channel indices for
some registers, but not others.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>

This sequence is incorrect for GP102/GP104 boards.  This is now being
handled correctly by the PMU subdev during preinit();
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It appears to be safe to access PTIMER on an unposted board with newer
chipsets.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GP102/GP104 require a harder reset of PMU prior to DEVINIT, or the IFR
image will hang.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just enough to hookup preinit reset(), which DEVINIT will depend on later.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

From visual inspection of traces, what we currently implement appears to
be identical to GP104.  Seems to work well enough too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes certain displays not being detected due to DPAUX errors.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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: 8539b37a ("drm/nouveau/gr: use NVIDIA-provided external firmwares")
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

MST encoders will make use of this to share code with SOR>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No code changes, just renames + shuffles.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is now handled by prepare_fb().  Legacy flips were the last user.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Made completely unreachable (and broken) by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Made completely unreachable by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Made completely unreachable (and broken) by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Make completely unreachable (and broken) by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This cannot currently be supported with atomic modesettting.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just a shuffle of blocks into an order consistent with the rest of the
code, renaming hdmi/audio funtions for atomic, and removal of unused
code.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>