This will serve as a basis for implementing some improvements to how
we recover the GPU from channel errors.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The previous commit simply changes the interface, but should result in
the same behaviour as previously.  This commit has been split out from
it as it can result in a different channel being selected.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We'll be wanting to reuse this logic in more places.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This will be used by callers outside of fifo interrupt handlers.
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>

FIFO gives us load/save/switch status, and we need to be able to determine
which direction a "switch" is failing during channel recovery.

In order to do this, we apparently need to query the engine itself.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This prevents *very* long waits while attempting to destroy channels
after a fault has occurred.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

These will be used to improve error recovery behaviour.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

There are instances (such as non-recoverable GPU page faults) where
NVKM decides that a channel's context is no longer viable, and will
be removed from the runlist.

This commit notifies the owner of the channel when this happens, so
it has the opportunity to take some kind of recovery action instead
of hanging.
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>

If the led class registration fails, we free drm->led but do not reset
it to NULL, which means that the suspend/resume/fini function will act
as if everything went well in init() and will likely crash the kernel.

This patch adds the missing drm->led = NULL.
Reported-by: Emmanuel Pescosta <emmanuelpescosta099@gmail.com>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Tested on a G92, seems to work. Confirmed by 8 mmiotraces.
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The issue was recorded in fd.o bug 27501, not 25701.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
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>

This will allow the DRM to share memory objects between clients later
down the track.

For the moment, the only immediate benefit is less logic required to
handle suspend/resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

These were a little insane.
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>

We never have any need for a double-linked list here, and as there's
generally a large number of these objects, replace it with a single-
linked list in order to save some memory.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We want a supervisor client of NVKM (such as the DRM) to be able to
allow sharing of resources (such as memory objects) between clients.

To allow this, the supervisor creates all its clients as children of
itself, and will use an upcoming ioctl to permit sharing.

Currently it's not possible for indirect clients to use subclients.
Supporting this will require an additional field in the main ioctl.
This isn't important currently, but will need to be fixed for virt.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Preparation for supporting subclients.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Preparation for supporting subclients, and also good for consistency.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Preparation for supporting subclients, and also good for consistency.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Preparation for supporting subclients.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The fields were already in struct nvkm_oclass for some reason (probably
as an accidental left-over).

Preparation for supporting subclients.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

nvkm_object::client refers to the client that created the object, which,
is currently always the same as the ioctl caller.

Upcoming patches introduce the concept of subclients, where a parent is
able to access the object trees of its children, making the above no
longer true.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Custom code is no longer needed here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Custom code is no longer needed here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It turns out we have a nice and convenient way of looking up a specific
object type already, by using the func pointer as a key.

This will be used to remove the separate object trees for each type we
need to be able to search for.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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