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>

Also removes the user-facing methods to these controls, as they're not
currently utilised by the DD anyway.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This data will be used by essentially every part of the supervisor
handling process.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

This essentially (unless the link becomes unstable and needs to be
re-trained) gives us a single entry-point to link training, during
supervisor handling, where we can ensure all routing is up to date.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

The aim here is to protect the OR against locking up when something
unexpected happens (such as the display disappearing during modeset,
or the DD misbehaving).
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Saves some trips across the aux channel.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This struct doesn't hold link configuration data anymore, so we can
limit its use to internal DP training (anx9805 handles training for
external DP).
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We care about this information outside of link training.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This hasn't been used since atomic.

We may want to re-implement "fast" DPMS at some point, but for now,
this just gets in the way.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This essentially replicates our current behaviour in a way that's
compatible with the new model that's emerging, so that we're able
to start porting the hw-specific functions to it.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

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

Primarily intended as a way to pass per-head state around during
supervisor handling, and share logic between NV50/GF119.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is to allow hw-specific code to instantiate output resources first,
so we can cull unsupported output paths based on them.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Not all users of nvkm_output_dp have been changed here.  The remaining
ones belong to code that's disappearing in upcoming commits.

This also modifies the debug level of some messages.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This isn't technically "output", but, "display/output path".

Not all users of nvkm_output have been changed here.  The remaining
ones belong to code that's disappearing in upcoming commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: 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>

This will ensure unspecified args are easily identified.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

As of DCB 4.1, these are not the same thing.

Compatibility temporarily in place until callers have been updated.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No (known) case yet, but other tables have been moving beyond 16-bits,
so we may as well be prepared.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Compatibility temporarily in place until all callers have been updated.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We already have a subdev pointer, from which we can locate the device's
BIOS subdev.  No need for a separate pointer.

Structure/callers not updated yet, as I want to batch more changes and
only touch the callers once.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

nvkm_timer_alarm() already handles this as part of protecting against
callers passing in no timeout value.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I only saw those values inside the vbios: 0xff, 0xfd, 0xfc, 0xfa for valid
rails.

No idea what the lower value does, but at least we get power readings on
a lot of Fermi GPUs with that.

v2: add missing parentheses
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>