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>

We care about this information outside of link training.
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>