drm/nouveau/disp/tu102-: prepare for GSP-RM

- (temporarily) disable if GSP-RM detected, will be added later
- pass "suspend" flag down to chipset-specific DISP code

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230918202149.4343-25-skeggsb@gmail.com

drm/nouveau/disp: add output backlight control methods

- preparation for GSP-RM

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-24-lyude@redhat.com

drm/nouveau/disp: remove SOR routing updates from supervisor

- these shouldn't be necessary now, and are done in acquire()/release()
- preparation for GSP-RM, where we don't control the supervisor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-23-lyude@redhat.com

drm/nouveau/disp: move HDMI config into acquire + infoframe methods

v2:
- fix typo in sorhdmi/g84 struct initialiser (kbuild test robot)
v3:
- less convoluted flow control in nvkm_uoutp_mthd_acquire_tmds() (lyude)
v4:
- we don't support hdmi on original nv50, don't try

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/disp: add supervisor mutex

Will be used to protect NVIF_CLASS_OUTP method calls from racing with
in-progress supervisor handling.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: add common channel class handling

Replaces a bunch of unnecessarily duplicated boilerplate in per-chipset
code with a simpler, common, implementation.

Channel "awaken" notify code is completely gone for now. KMS has never
made use of it so far, and event notify handling is about to be changed
in general anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: split sor hda funcs out to their own struct

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: split sor dp funcs out to their own struct

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: replace hda func pointer check with flag

Simpler, and less error-prone than a separate set of function pointers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: merge nv50_disp_new_() and nvkm_disp_new()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: group supervisor-related struct members

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: merge head/outp/ior code into chipset files

No changes to code at all here, just shuffling it around and removing
a bunch of (now unnecessary) forward-declarations from headers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: add common class handling between <nv50 and >=nv50

About to expose head/output path/connector objects everywhere, so we will
need support for child classes prior to nv50 now.

Somewhat cleaner than the code >=nv50 used previously.

v2:
- use ?: (lyude)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: collapse nv50_disp into nvkm_disp

Dump of one struct's members into another, with a couple of list
renames because of collisions.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: collapse nv50_disp_func into nvkm_disp_func

Aside from a chicken-and-egg problem with a duplicate 'root' member,
this is a straight dump of function pointers from one struct into
another.

The left-over wrapping mess in >=nv50 structs will be fixed later.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau/disp: switch to instanced constructor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/disp/gf119-: decode exception reason to human-readable string

We also change the error strings to match NVIDIA's naming.

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

drm/nouveau/disp/nv50-: merge handling of pio and dma channels

Unnecessarily complicated, and a barrier to cleanly supporting Volta.

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

drm/nouveau/disp/nv50-: initialise from the engine, rather than the user object

Engines are initialised on an as-needed basis, so this results in the
same behaviour, whilst allowing us to simplify things a bit.

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

drm/nouveau/disp/nv50-: fetch mask of available sors during oneinit

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

drm/nouveau/disp/nv50-: fetch mask of available dacs during oneinit

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

drm/nouveau/disp/nv50-: fetch mask of available heads during oneinit

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

drm/nouveau/disp/nv50-: implement a common supervisor 3.0

This makes use of all the additional routing and state added in previous
commits, making it possible to deal with GM20x macro link routing, while
also sharing code between the NV50 and GF119 implementations.

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

drm/nouveau/disp/nv50-: implement a common supervisor 2.2

This makes use of all the additional routing and state added in previous
commits, making it possible to deal with GM20x macro link routing, while
also sharing code between the NV50 and GF119 implementations.

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

drm/nouveau/disp/nv50-: implement a common supervisor 2.1

This makes use of all the additional routing and state added in previous
commits, making it possible to deal with GM20x macro link routing, while
also sharing code between the NV50 and GF119 implementations.

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

drm/nouveau/disp/nv50-: implement a common supervisor 2.0

This makes use of all the additional routing and state added in previous
commits, making it possible to deal with GM20x macro link routing, while
also sharing code between the NV50 and GF119 implementations.

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

drm/nouveau/disp/nv50-: implement a common supervisor 1.0

This makes use of all the additional routing and state added in previous
commits, making it possible to deal with GM20x macro link routing, while
also sharing code between the NV50 and GF119 implementations.

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

drm/nouveau/disp: introduce acquire/release display path methods

These exist to give NVKM information on the set of display paths that
the DD needs to be active at any given time.

Previously, the supervisor attempted to determine this solely from OR
state, but there's a few configurations where this information on its
own isn't enough to determine the specific display paths in question:

- ANX9805, where the PIOR protocol for both DP and TMDS is TMDS.
- On a device using DCB Switched Outputs.
- On GM20x and newer, with a crossbar between the SOR and macro links.

After this commit, the DD tells NVKM *exactly* which display path it's
attempting a modeset on.

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

drm/nouveau/disp: remove hw-specific customisation of output paths

All of the necessary hw-specific logic is now handled at the output
resource level, so all of this can go away.

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

drm/nouveau/disp/gt215-: port HDA ELD controls to nvkm_ior

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

drm/nouveau/disp/g84-: port OR HDMI control to nvkm_ior

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

drm/nouveau/disp/nv50-: port OR manual sink detection to nvkm_ior

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

drm/nouveau/disp/nv50-: port OR power state control to nvkm_ior

Also removes the user-facing methods to these controls, as they're not
currently utilised by the DD anyway.

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

drm/nouveau/disp/nv50-: fetch head/OR state at beginning of supervisor

This data will be used by essentially every part of the supervisor
handling process.

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

drm/nouveau/disp/nv50-: execute supervisor on its own workqueue

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

drm/nouveau/disp/dp: only check for re-train when the link is active

An upcoming commit will limit link training to only when the sink is
meant to be displaying an image.

We still need IRQs enabled even when the link isn't trained (for MST
messages), but don't want to train the link unnecessarily.

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

drm/nouveau/disp: fork off some new hw-specific implementations

Upcoming commits make supervisor handling share code between the NV50
and GF119 implementations. Because of this, and a few other cleanups,
we need to allow some additional customisation.

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

drm/nouveau/disp: introduce input/output resource abstraction

In order to properly support the SOR -> SOR + pad macro separation
that occurred with GM20x GPUs, we need to separate OR handling out
of the output path code.

This will be used as the base to support ORs (DAC, SOR, PIOR).

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

drm/nouveau/disp: common implementation of scanoutpos method in nvkm_head

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

drm/nouveau/disp: move vblank_{get,put} methods into nvkm_head

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

drm/nouveau/disp: introduce object to track per-head functions/state

Primarily intended as a way to pass per-head state around during
supervisor handling, and share logic between NV50/GF119.

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

drm/nouveau/disp: shuffle functions around

Upcoming changes to split OR from output path drastically change the
placement of various operations.

In order to make the real changes clearer, do the moving around part
ahead of time.

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

drm/nouveau/disp/g94-: stop listening for dp (sst) retrain irq when disabling link

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

drm/nouveau/disp/sor/gf119-: add method to control mst enable

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

drm/nouveau/disp/dp: remove workqueue for link training

There haven't been any callers from an atomic context for a while now,
so let's remove the extra complexity.

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

drm/nouveau/disp/gp104: initial support

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

drm/nouveau/disp/nv50-: fix lookup of udisp table under certain circumstances

Some VBIOS have separate tables for each link of a given output path,
which means we have to specify the specific link we're using instead
of all possible links.

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

drm/nouveau/bios/disp: fix handling of "match any protocol" entries

As it turns out, a value of 0xff means "any protocol" and not "VGA".

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/nouveau/disp: activate dual link TMDS links only when possible

Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actually possible and requested.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
enable extra config bit]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: convert to new-style nvkm_engine

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

drm/nouveau/devinit: convert to new-style nvkm_subdev

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

drm/nouveau/bios: convert to new-style nvkm_subdev

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

drm/nouveau/disp: convert user classes to new-style nvkm_object

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

drm/nouveau/disp: split user classes out from engine implementations

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