Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-7-dakr@redhat.com

Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-5-dakr@redhat.com

Merge and cleanup the two headers into a single description of the
object API. Also move all the documentation to the implementation and
drop unnecessary includes from the header.

No functional change.

v2: minimal checkpatch.pl cleanup

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-4-christian.koenig@amd.com

DRM uses this to setup fence-related items.

- nouveau_chan.runlist will always be "0" for the moment, not an issue
  as GPUs prior to ampere have system-wide channel IDs,

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

This removes support for accelerated fbcon rendering, and fixes a number
of races/crashes/issues around suspend/resume/module unload etc.

Losing HW accelerated rendering isn't ideal, but it's been significantly
reduced in performance since the removal of accelerated scrolling in the
kernel anyway - not to mention, can be racey (skips cpu<->gpu sync) from
certain contexts.

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

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

There's no good reason for this to be a mutex, and once the layers of
workqueues have been untangled, nouveau_connector_hpd() can be called
from IRQ context and won't be able to take a mutex.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

Userspace never ended up using this to be clever about dealing with
channel death, and it won't be, not like this anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Rather than protecting the nouveau_drm clients list with the lock within
the "client" nouveau_cli, add a dedicated lock to serialize access to
the list. This is both clearer and necessary to avoid lockdep being
upset with us when we need to iterate through all the clients in the
list and potentially lock their mutex, which is the same class as the
lock protecting the entire list.

Cc: stable@vger.kernel.org # 5.4+
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-3-jcline@redhat.com
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14

This is just another feature which is only used by VMWGFX, so move
it into the driver instead.

I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.

v2: fix typo in KFD and avoid 64bit divide
v3: fix init order in VMWGFX
v4: use pdev sysfs reference instead of drm

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Zack Rusin <zackr@vmware.com> (v3)
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210208133226.36955-2-christian.koenig@amd.com

Noticed that I wasn't paying close enough attention the last time I looked
at our audio callbacks, as I completely missed the fact that we were
figuring out which audio-enabled connector goes to each encoder by checking
it's state, but without grabbing any of the appropriate modesetting locks
to do so.

That being said however: trying to grab modesetting locks in our audio
callbacks would be very painful due to the potential for locking inversion
between HDA and DRM. So, let's instead just copy what i915 does again - add
our own audio lock to protect audio related state, and store each audio
enabled connector in each nouveau_encoder struct so that we don't need to
check any atomic states.

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

Rename ttm_bo_device to ttm_device.
Rename ttm_bo_driver to ttm_device_funcs.
Rename ttm_bo_global to ttm_global.

Move global and device related functions to ttm_device.[ch].

No functional change.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/415222/

ttm_module.h deals with internals of TTM and should never
be include outside of it.

v2: also move the file around

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/404885/

It should be able to handle all cases now.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com>
Tested-by: Huang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/397082/?series=83051&rev=1

While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.

In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.

v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
v5: rebased and keep the mem.bus init in TTM.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/388643/

Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a connector hotplug happens to occur in parallel
with a modeset.

I haven't seen this actually happen yet, but since we're cleaning up
nouveau's hotplug handling code anyway and we already have a hpd worker,
we can simply fix this by only relying on the HPD worker to actually
reprobe connectors when we receive a HPD IRQ. We also add a mask to
nouveau_drm to keep track of which connectors are waiting to be reprobed
in response to an HPD IRQ.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-13-lyude@redhat.com

This name better reflects what the object does. I didn't rename
all the pointers it seemed too messy.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-60-airlied@gmail.com

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.

Depending on the used kernel there might be messages like those in demsg:

"nouveau 0000:01:00.0: Refused to change power state, currently in D3"
"nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.

It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.

Signed-off-by: Karol Herbst <kherbst@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Mika Westerberg <mika.westerberg@intel.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623


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

This patch adds the support for the notification of HD-audio hotplug
via the already existing drm_audio_component framework.  This allows
us more reliable hotplug notification and ELD transfer without
accessing HD-audio bus; it's more efficient, and more importantly, it
works without waking up the runtime PM.

The implementation is rather simplistic: nouveau driver provides the
get_eld ops for HD-audio, and it notifies the audio hotplug via
pin_eld_notify callback upon each nv50_audio_enable() and _disable()
call.  As the HD-audio pin assignment seems corresponding to the CRTC,
the crtc->index number is passed directly as the zero-based port
number.

The bind and unbind callbacks handle the device-link so that it
assures the PM call order.

Link: https://lore.kernel.org/r/20190722143815.7339-3-tiwai@suse.de


Reviewed-by: Lyude Paul <lyude@redhat.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Allow better abstraction of the drm_debug global variable in the
future. No functional changes.

v2: move unlikely() to drm_debug_enabled()

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/34a1e7db6eab6467c6607d9a57581d1de75d87da.1572258936.git.jani.nikula@intel.com

This is something that got noticed a while ago back when I was fixing a
large number of runtime PM related issues in nouveau, but never got
fixed:

https://patchwork.freedesktop.org/series/46815/#rev7



It's not safe to iterate the entire list of CRTCs in
nv50_disp_atomic_commit(), as we could be doing a non-blocking modeset
on one CRTC in parallel with one or more other CRTCs. Likewise, this
means it's also not safe to do so in order to track runtime PM state.
While this code is certainly wrong, so far the only issues I've seen
this cause in the wild is the occasional PM ref unbalance after an
atomic check failure + module reloading (since the PCI device will
outlive nouveau in such scenarios).

So, do this far more elegantly: grab a runtime PM ref across the modeset
and commit tail, then grab/put references for each CRTC enable/disable.
This also ends up being much simpler then the previous broken solution
we had.

Finally, since we've removed all it's users: get rid of
nouveau_drm->have_disp_power_ref.

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

remove duplicate inclusion of nvif/device.h

Issue identified by includecheck

Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Drop the deprecated drmP.h header from nouveau_drv.h.
Fix fallout in other parts of the driver.

Build tested using allmodconfig and allyesconfig.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The bulk SPDX addition made all these files into GPL-2.0 licensed files.
However the remainder of the project is MIT-licensed, these files
(primarily header files) were simply missing the boiler plate and got
caught up in the global update.

Fixes: b2441318 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
value. The only exception is vboxvideo, which is being converted to the
new offset by this patch. Unifying the constants in a single place
simplifies the driver code.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Device memory can be use in SVM, in which case we do not have any of
the existing buffer object. This commit add infrastructure to allow
use of device memory without nouveau_bo. Again this is a temporary
solution until a rework of GPU memory management.

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>

This uses HMM to mirror a process' CPU page tables into a channel's page
tables, and keep them synchronised so that both the CPU and GPU are able
to access the same memory at the same virtual address.

While this code also supports Volta/Turing, it's only enabled for Pascal
GPUs currently due to channel recovery being unreliable right now on the
later GPUs.

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

For a channel to make use of SVM features, it requires a different GPU MMU
configuration than we would normally use, which is not desirable to switch
to unless a client is actively going to use SVM.

In order to supporting SVM without more extensive changes to the userspace
interfaces, the SVM_INIT ioctl needs to replace the previous configuration
safely.

The only way we can currently do this safely, accounting for some unlikely
failure conditions, is to allocate the new VMM without destroying the last
one, and prioritising the SVM-enabled configuration in the code that cares.

This will get cleaned up again further down the track.

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

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

Make sure that the global BO state is always correctly initialized.

This allows removing all the device code to initialize it.

v2: fix up vbox (Alex)

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

As the name says we only need one global instance of ttm_mem_global.

Drop all the driver initialization and just use a single exported
instance which is initialized during BO global initialization.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Currently module unloading is broken in nouveau due to a rather annoying
race condition resulting from nouveau_backlight.c having gone a bit
stale over time:

[ 1960.791143] ==================================================================
[ 1960.791394] BUG: KASAN: use-after-free in nouveau_backlight_exit+0x112/0x150 [nouveau]
[ 1960.791460] Read of size 4 at addr ffff88075accf350 by task zsh/11185
[ 1960.791521]
[ 1960.791545] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G           O      4.18.0Lyude-Test+ #4
[ 1960.791580] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018
[ 1960.791628] Call Trace:
[ 1960.791680]  dump_stack+0xa4/0xfd
[ 1960.791721]  print_address_description+0x71/0x239
[ 1960.791833]  ? nouveau_backlight_exit+0x112/0x150 [nouveau]
[ 1960.791877]  kasan_report.cold.6+0x242/0x2fe
[ 1960.791919]  __asan_report_load4_noabort+0x19/0x20
[ 1960.792012]  nouveau_backlight_exit+0x112/0x150 [nouveau]
[ 1960.792081]  nouveau_display_destroy+0x76/0x150 [nouveau]
[ 1960.792150]  nouveau_drm_device_fini+0xb7/0x190 [nouveau]
[ 1960.792265]  nouveau_drm_device_remove+0x14b/0x1d0 [nouveau]
[ 1960.792347]  ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau]
[ 1960.792378]  ? trace_hardirqs_on_caller+0x38b/0x570
[ 1960.792406]  ? trace_hardirqs_on+0xd/0x10
[ 1960.792472]  nouveau_drm_remove+0x37/0x50 [nouveau]
[ 1960.792502]  pci_device_remove+0x112/0x2d0
[ 1960.792530]  ? pcibios_free_irq+0x10/0x10
[ 1960.792558]  ? kasan_check_write+0x14/0x20
[ 1960.792587]  device_release_driver_internal+0x35c/0x650
[ 1960.792617]  device_release_driver+0x12/0x20
[ 1960.792643]  pci_stop_bus_device+0x172/0x1e0
[ 1960.792671]  pci_stop_and_remove_bus_device_locked+0x1a/0x30
[ 1960.792715]  remove_store+0xcb/0xe0
[ 1960.792753]  ? sriov_numvfs_store+0x2e0/0x2e0
[ 1960.792779]  ? __lock_is_held+0xb5/0x140
[ 1960.792808]  ? component_add+0x530/0x530
[ 1960.792834]  dev_attr_store+0x3f/0x70
[ 1960.792859]  ? sysfs_file_ops+0x11d/0x170
[ 1960.792885]  sysfs_kf_write+0x104/0x150
[ 1960.792915]  ? sysfs_file_ops+0x170/0x170
[ 1960.792940]  kernfs_fop_write+0x24f/0x400
[ 1960.792978]  ? __lock_acquire+0x6ea/0x47f0
[ 1960.793021]  __vfs_write+0xeb/0x760
[ 1960.793048]  ? kernel_read+0x130/0x130
[ 1960.793076]  ? __lock_is_held+0xb5/0x140
[ 1960.793107]  ? rcu_read_lock_sched_held+0xdd/0x110
[ 1960.793135]  ? rcu_sync_lockdep_assert+0x78/0xb0
[ 1960.793162]  ? __sb_start_write+0x183/0x220
[ 1960.793189]  vfs_write+0x14d/0x4a0
[ 1960.793229]  ksys_write+0xd2/0x1b0
[ 1960.793255]  ? __ia32_sys_read+0xb0/0xb0
[ 1960.793298]  ? fput+0x1d/0x120
[ 1960.793324]  ? filp_close+0xf3/0x130
[ 1960.793349]  ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 1960.793380]  __x64_sys_write+0x73/0xb0
[ 1960.793407]  do_syscall_64+0xaa/0x400
[ 1960.793433]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1960.793460] RIP: 0033:0x7f59df433164
[ 1960.793486] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
[ 1960.793541] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1960.793576] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164
[ 1960.793620] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001
[ 1960.793665] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80
[ 1960.793696] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760
[ 1960.793730] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002
[ 1960.793768]
[ 1960.793790] Allocated by task 11167:
[ 1960.793816]  save_stack+0x43/0xd0
[ 1960.793841]  kasan_kmalloc+0xc4/0xe0
[ 1960.793880]  kasan_slab_alloc+0x11/0x20
[ 1960.793905]  kmem_cache_alloc+0xd7/0x270
[ 1960.793944]  getname_flags+0xbd/0x520
[ 1960.793969]  user_path_at_empty+0x23/0x50
[ 1960.793994]  do_faccessat+0x1fc/0x5d0
[ 1960.794018]  __x64_sys_access+0x59/0x80
[ 1960.794043]  do_syscall_64+0xaa/0x400
[ 1960.794067]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1960.794093]
[ 1960.794127] Freed by task 11167:
[ 1960.794152]  save_stack+0x43/0xd0
[ 1960.794190]  __kasan_slab_free+0x139/0x190
[ 1960.794215]  kasan_slab_free+0xe/0x10
[ 1960.794239]  kmem_cache_free+0xcb/0x2c0
[ 1960.794264]  putname+0xad/0xe0
[ 1960.794287]  filename_lookup.part.59+0x1f1/0x360
[ 1960.794313]  user_path_at_empty+0x3e/0x50
[ 1960.794338]  do_faccessat+0x1fc/0x5d0
[ 1960.794362]  __x64_sys_access+0x59/0x80
[ 1960.794393]  do_syscall_64+0xaa/0x400
[ 1960.794421]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1960.794461]
[ 1960.794483] The buggy address belongs to the object at ffff88075acceac0
[ 1960.794483]  which belongs to the cache names_cache of size 4096
[ 1960.794540] The buggy address is located 2192 bytes inside of
[ 1960.794540]  4096-byte region [ffff88075acceac0, ffff88075accfac0)
[ 1960.794581] The buggy address belongs to the page:
[ 1960.794609] page:ffffea001d6b3200 count:1 mapcount:0 mapping:ffff880778e4b1c0 index:0x0 compound_mapcount: 0
[ 1960.794651] flags: 0x8000000000008100(slab|head)
[ 1960.794679] raw: 8000000000008100 ffffea001d39e808 ffffea001d39ea08 ffff880778e4b1c0
[ 1960.794739] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
[ 1960.794785] page dumped because: kasan: bad access detected
[ 1960.794813]
[ 1960.794834] Memory state around the buggy address:
[ 1960.794861]  ffff88075accf200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1960.794894]  ffff88075accf280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1960.794925] >ffff88075accf300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1960.794956]                                                  ^
[ 1960.794985]  ffff88075accf380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1960.795017]  ffff88075accf400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1960.795061] ==================================================================
[ 1960.795106] Disabling lock debugging due to kernel taint
[ 1960.795131] ------------[ cut here ]------------
[ 1960.795148] ida_remove called for id=1802201963 which is not allocated.
[ 1960.795193] WARNING: CPU: 7 PID: 11185 at lib/idr.c:521 ida_remove+0x184/0x210
[ 1960.795213] Modules linked in: nouveau(O) mxm_wmi ttm i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm joydev vfat fat intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul iTCO_wdt psmouse wmi_bmof mei_me tpm_tis mei tpm_tis_core tpm i2c_i801 thinkpad_acpi pcc_cpufreq crc32c_intel serio_raw xhci_pci xhci_hcd wmi video i2c_dev i2c_core
[ 1960.795305] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G    B      O      4.18.0Lyude-Test+ #4
[ 1960.795330] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018
[ 1960.795352] RIP: 0010:ida_remove+0x184/0x210
[ 1960.795370] Code: 4c 89 f7 e8 ae c8 00 00 eb 22 41 83 c4 02 4c 89 e8 41 83 fc 3f 0f 86 64 ff ff ff 44 89 fe 48 c7 c7 20 94 1e 83 e8 54 ed 81 fe <0f> 0b 48 b8 00 00 00 00 00 fc ff df 48 01 c3 c7 03 00 00 00 00 c7
[ 1960.795402] RSP: 0018:ffff88074d4df7b8 EFLAGS: 00010082
[ 1960.795421] RAX: 0000000000000000 RBX: 1ffff100e9a9befa RCX: ffffffff81479975
[ 1960.795440] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88077c1de690
[ 1960.795460] RBP: ffff88074d4df878 R08: ffffed00ef83bcd3 R09: ffffed00ef83bcd2
[ 1960.795479] R10: ffffed00ef83bcd2 R11: ffff88077c1de697 R12: 000000000000036b
[ 1960.795498] R13: 0000000000000202 R14: ffffffffa0aa7fa0 R15: 000000006b6b6b6b
[ 1960.795518] FS:  00007f59e0995b80(0000) GS:ffff88077c1c0000(0000) knlGS:0000000000000000
[ 1960.795553] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1960.795571] CR2: 00007f59e09a2010 CR3: 00000004a1a70005 CR4: 00000000003606e0
[ 1960.795596] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1960.795629] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1960.795649] Call Trace:
[ 1960.795667]  ? ida_destroy+0x1d0/0x1d0
[ 1960.795686]  ? kasan_check_write+0x14/0x20
[ 1960.795704]  ? do_raw_spin_lock+0xc2/0x1c0
[ 1960.795724]  ida_simple_remove+0x26/0x40
[ 1960.795794]  nouveau_backlight_exit+0x9d/0x150 [nouveau]
[ 1960.795867]  nouveau_display_destroy+0x76/0x150 [nouveau]
[ 1960.795930]  nouveau_drm_device_fini+0xb7/0x190 [nouveau]
[ 1960.795989]  nouveau_drm_device_remove+0x14b/0x1d0 [nouveau]
[ 1960.796047]  ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau]
[ 1960.796067]  ? trace_hardirqs_on_caller+0x38b/0x570
[ 1960.796089]  ? trace_hardirqs_on+0xd/0x10
[ 1960.796146]  nouveau_drm_remove+0x37/0x50 [nouveau]
[ 1960.796167]  pci_device_remove+0x112/0x2d0
[ 1960.796186]  ? pcibios_free_irq+0x10/0x10
[ 1960.796218]  ? kasan_check_write+0x14/0x20
[ 1960.796237]  device_release_driver_internal+0x35c/0x650
[ 1960.796257]  device_release_driver+0x12/0x20
[ 1960.796289]  pci_stop_bus_device+0x172/0x1e0
[ 1960.796308]  pci_stop_and_remove_bus_device_locked+0x1a/0x30
[ 1960.796328]  remove_store+0xcb/0xe0
[ 1960.796345]  ? sriov_numvfs_store+0x2e0/0x2e0
[ 1960.796364]  ? __lock_is_held+0xb5/0x140
[ 1960.796383]  ? component_add+0x530/0x530
[ 1960.796401]  dev_attr_store+0x3f/0x70
[ 1960.796419]  ? sysfs_file_ops+0x11d/0x170
[ 1960.796436]  sysfs_kf_write+0x104/0x150
[ 1960.796454]  ? sysfs_file_ops+0x170/0x170
[ 1960.796471]  kernfs_fop_write+0x24f/0x400
[ 1960.796488]  ? __lock_acquire+0x6ea/0x47f0
[ 1960.796520]  __vfs_write+0xeb/0x760
[ 1960.796538]  ? kernel_read+0x130/0x130
[ 1960.796556]  ? __lock_is_held+0xb5/0x140
[ 1960.796590]  ? rcu_read_lock_sched_held+0xdd/0x110
[ 1960.796608]  ? rcu_sync_lockdep_assert+0x78/0xb0
[ 1960.796626]  ? __sb_start_write+0x183/0x220
[ 1960.796648]  vfs_write+0x14d/0x4a0
[ 1960.796666]  ksys_write+0xd2/0x1b0
[ 1960.796684]  ? __ia32_sys_read+0xb0/0xb0
[ 1960.796701]  ? fput+0x1d/0x120
[ 1960.796732]  ? filp_close+0xf3/0x130
[ 1960.796749]  ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 1960.796768]  __x64_sys_write+0x73/0xb0
[ 1960.796800]  do_syscall_64+0xaa/0x400
[ 1960.796818]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1960.796836] RIP: 0033:0x7f59df433164
[ 1960.796854] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
[ 1960.796884] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1960.796906] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164
[ 1960.796926] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001
[ 1960.796946] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80
[ 1960.796966] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760
[ 1960.796985] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002
[ 1960.797008] irq event stamp: 509990
[ 1960.797026] hardirqs last  enabled at (509989): [<ffffffff8119ff78>] flush_work+0x4b8/0x6d0
[ 1960.797063] hardirqs last disabled at (509990): [<ffffffff8297c395>] _raw_spin_lock_irqsave+0x25/0x60
[ 1960.797085] softirqs last  enabled at (509744): [<ffffffff82c005ad>] __do_softirq+0x5ad/0x8c0
[ 1960.797121] softirqs last disabled at (509735): [<ffffffff8115aa15>] irq_exit+0x1a5/0x1e0
[ 1960.797142] ---[ end trace fb1342325f1846b8 ]---

While I haven't actually gone into the details of what's causing this to
happen (maybe the kernel removes the backlight device in the device core
before we get to it?), it doesn't really matter anyway because the way
nouveau handles backlights has long since been deprecated.

According to the documentation on the drm_connector->late_register()
hook, the ->late_register() hook should be used for adding extra
connector-related devices. Vice versa, the ->early_unregister() hook is
meant to be used for removing those devices.

So: gut nouveau_drm->bl_list and nouveau_drm->backlight, and replace
them with per-connector backlight structures. Additionally, move
backlight registration/teardown into the ->late_register() and
->early_unregister() hooks so that DRM can give us a chance to remove
the backlight before the connector is even removed. This appears to fix
the problem once and for all.

Changes since v2:
- Use NV_INFO_ONCE for printing GMUX information, since otherwise this
  will end up printing that message for as many times as we have
  connectors

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Since we're about to use this in nouveau_backlight.c. Same thing as
DRM_WARN_ONCE, DRM_INFO_ONCE, etc...

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Commit 5addcf0a ("nouveau: add runtime PM support (v0.9)") prevents
runtime suspend of the GPU if its integrated HDA controller is not bound
to a driver.  The rationale appears to be that probing the HDA fails if
the GPU is in D3cold.

However we now use a device link to ensure that the GPU is runtime
resumed while the HDA controller is probed, rendering this safety
measure obsolete.  Remove it.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Denis Lisov <dennis.lissov@gmail.com>       # Nvidia Optimus
Tested-by: Peter Wu <peter@lekensteyn.nl>              # Nvidia Optimus
Tested-by: Lukas Wunner <lukas@wunner.de>              # MacBook Pro
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/77e0ab74f3377ea9b6acf8fab624acfb4f7dbeca.1520068884.git.lukas@wunner.de

Fixes bug on Tegra where we'd strip kind information from system memory
(ie. all) buffers, resulting in misrendering.

Behaviour on dGPU should be unchanged.

Reported-by: Thierry Reding <treding@nvidia.com>
Fixes: d7722134 ("drm/nouveau: switch over to new memory and vmm interfaces")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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