Every codepath in nouveau that loops through the connector list
currently does so using the old method, which is prone to race
conditions from MST connectors being created and destroyed. This has
been causing a multitude of problems, including memory corruption from
trying to access connectors that have already been freed!
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The bo array has req->nr_buffers elements so the > should be >= so we
don't read beyond the end of the array.

Fixes: a1606a95 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It was possible for this to be skipped when shutting down MST streams, and
leaving the core channel interlocked with a wndw channel update that never
happens - leading to a hung display.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Tested-By: NLyude Paul <lyude@redhat.com>

Ctxdmas for cursors from all heads are setup in the core channel, and due
to us tracking allocated handles per-window, we were failing with -EEXIST
on multiple-head setups trying to allocate duplicate handles.

The cursor code is hardcoded to use the core channel vram ctxdma already,
so just skip ctxdma allocation for cursor fbs to fix the issue.

Fixes: 5bca1621 ("drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows")
Reported-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Inserted wait-for-gr-idle in the places it seems that RM does it, seems
to prevent some random mmio timeouts on Quadro GV100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It's better to use "list_for_each_entry_from_reverse" for iterating list
than "for loop" as it makes the code more clear to read.
This patch replace "for loop" with "list_for_each_entry_from_reverse"
and "start" variable with "cstate" which helps in refactoring
the code and also "cstate" variable is more commonly used in the other
functions.

changes in v2:
"start" variable is removed, before "cstate" variable was removed
but "cstate" is more common so preferred "cstate" over "start".
Signed-off-by: NArushi Singhal <arushisinghal19971997@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A NV34 GPU was seeing temp and pwm entries in hwmon, which would error
out when read. These should not have been visible, but also the whole
hwmon object should just not have been registered in the first place.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, nouveau_dsm_get_client_id(), returns an 'int'.

Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.

Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.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>

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

Appears to be compatible with GP102.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Appears to be compatible with GM107.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

VEID support hacked in here, as it's the most convenient place for now.

Will be refined once it's better understood.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP102.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Can't imagine this will be any different.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GK20A.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GF100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GM107.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GM200.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GK104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GM200.
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>

No real surprises here so far.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP100.
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>