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>

This is according to what we have in nvbios.

Fixes "ERROR: Can't get value of subfeature in0_min: Can't read" errors
in sensors for some GPUs.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Enable stereoscopic output for HDMI and DisplayPort connectors on
NV50+ (G80+) hardware.  We do not enable stereoscopy on older
hardware in case there is some older board that still has HDMI
output but for which we have no logic for setting the Vendor
InfoFrame.

With this, I get an obvious 3D output when using the "testdisplay"
program from intel-gpu-tools with the "-3" parameter and outputting
to a 3D-capable HDMI display, for all available 3D modes (be they
TB, SBSH, or FP) on all four G80+ DISPs.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>

Frame-packing modes add an extra vtotal raster lines to each frame
above and beyond what the basic mode description calls for.
Account for this during scaler configuration (possibly a bit of a
hack), during CRTC configuration (clearly not a hack), and when
checking that a mode is valid for a given connector (cribbed from
the i915 driver).
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any InfoFrame that is not provided, and disable
the Vendor InfoFrame when disabling the output.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any InfoFrame that is not provided, and disable
the Vendor InfoFrame when disabling the output.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic") InfoFrame.

Also don't enable any AVI or Vendor InfoFrame that is not provided,
and disable the Vendor InfoFrame when disabling the output.

Ignore the Audio InfoFrame: We don't supply it, and altering HDMI
audio semantics (for better or worse) on this hardware is out of
scope for me at this time.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any AVI or Vendor InfoFrame that is not provided,
and disable the Vendor InfoFrame when disabling the output.

Ignore the Audio InfoFrame: We don't supply it, and altering HDMI
audio semantics (for better or worse) on this hardware is out of
scope for me at this time.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

HDMI InfoFrames are passed to NVKM as bags of bytes, but the
hardware needs them to be packed into words.  Rather than having
four (or more) copies of the packing logic introduce a single copy
now, in a central place.

We currently need these for AVI and Vendor InfoFrames, but we may
also expect to need them for Audio InfoFrames at some point.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have mechanism by which to pass mode-dependent HDMI
InfoFrames to the low-level hardware driver, it is incumbent upon
us to do so.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>