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

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

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.

We're no longer touching the overlay channel usage bounds as of this
commit.  The code to do so is in place for when overlay planes are
added.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.

As of this commit, we're no longer bothering to point the core surface
at a valid framebuffer.  Prior to this, we'd initially point the core
channel to the framebuffer passed in a mode_set()/mode_set_base(), and
then use the base channel for any page-flip updates, leaving the core
channel pointing at stale information.

The important thing here is to configure the core surface parameters in
such a way that EVO's error checking is satisfied.

TL;DR: The situation isn't too much different to before.

There may be brief periods of times during modesets where the (garbage)
core surface will be showing.  This issue will be resolved once support
for atomic commits has been implemented and we're able to interlock the
updates that involve multiple channels.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit separates the calculation of EVO state from the commit, in
order to make the same code useful for atomic modesetting.

The legacy interfaces have been wrapped on top of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Will be useful in debugging the transition to atomic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Sometimes we load with a sink already in MST mode.  If, however, we can't
or don't want to use MST, we need to be able to switch it back to SST.

This commit instantiates a stub topology manager for any output path that
we believe (the detection of this could use some improvement) has support
for MST, and adds the connector detect() logic for detecting sink support
and switching between modes.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

This is different from the equivilant functions in the atomic helpers in
that we fully disable the pipe instead of just setting it to inactive.

We do this (primarily) to ensure the framebuffer cleanup paths are hit,
allowing buffers to be un-pinned from memory so they can be evicted to
system memory and not lose their contents while suspended.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

These will also be used by MST connectors.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This commit implements the atomic property hooks for a connector, and
wraps the legacy interface handling on top of those.

For the moment, a full modeset will be done after any property change
in order to ease subsequent changes.  The optimised behaviour will be
restored for Tesla and later (earlier boards always do full modesets)
once atomic commits are implemented.

Some functions are put under the "nouveau_conn" namespace now, rather
than "nouveau_connector", to distinguish functions that will work for
(upcoming) MST connectors too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This will ensure we have some kind of initial atomic state for all objects
after initialisation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

nouveau_display_fini() is responsible for quiescing the hardware, so
this is where such actions belong.

More than that, nouveau_display_fini() switches off the receiving of
sink irqs, which MST will require while shutting down an active head.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This primarily existed to ensure the DP link got retrained, and is
now unnecessary as that's handled by NVKM already.

For anything beyond that, we send an event to userspace and let it
decide on an appropriate action to take.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Transitional step towards properly refcounting the fbcon fb.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

No need to store the pointer ourselves when it's already present in
the base struct.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

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>

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

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

'iommu_domain_alloc()' returns NULL in case of error, not an error pointer.
So test it accordingly.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

gm20b's FB has the same capabilities as gm200, minus the ability to
allocate RAM. Create a device that reflects this instead of re-using the
gk20a device which may be incorrect.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-By: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

gk20a's FB is not special compared to other Kepler chips, besides the
fact it does not have VRAM. Use the regular gf100 hooks instead of the
incomplete versions we rewrote.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-By: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The gf100 constructor should be called, otherwise we will allocate a
smaller object than expected. This was without effect so far because
gk20a did not allocate a page, but with gf100's page allocation moved
to the oneinit() hook this problem has become apparent.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>