summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau
AgeCommit message (Collapse)AuthorFilesLines
2021-02-11drm/nouveau/fuse: switch to instanced constructorBen Skeggs10-67/+67
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/fb: switch to instanced constructorBen Skeggs43-210/+206
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/fault: switch to instanced constructorBen Skeggs11-33/+30
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/devinit: switch to instanced constructorBen Skeggs25-158/+153
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/clk: switch to instanced constructorBen Skeggs19-129/+128
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/bus: switch to instanced constructorBen Skeggs12-106/+108
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/bios: switch to instanced constructorBen Skeggs6-92/+90
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/bar: switch to instanced constructorBen Skeggs16-87/+91
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/acr: switch to instanced constructorBen Skeggs13-43/+46
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/nvkm: add macros for subdev layoutBen Skeggs5-1/+78
Rather than having to add new engines / engine instances to multiple places, define everything in include/nvkm/core/layout.h and use macros to generate the required plumbing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/device: pass instance id when looking up a subdev/engineBen Skeggs13-109/+41
This switches to using the subdev list for lookup, and otherwise should be a no-op aside from switching the function signatures. Callers will be transitioned to split type+inst individually. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/subdev: track type+instance separatelyBen Skeggs3-78/+115
We use subdev id bitmasks (as a u64) in a number of places, and GA100 adds enough new engine instances that we run out of bits. We could alias IDs of engines that no longer exist, but it's cleaner for a number of reasons to just split the subdev index into a subdev type, and instance ID instead. Just a lot more painful to do. This magics up the values for old-style subdev constructors, and provides a way to incrementally transition each subdev to the new style. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/subdev: store full subdev name in structBen Skeggs17-35/+29
Much easier to store this to avoid having to reconstruct a string for a specific subdev, taking into account whether it's instanced or not. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/subdev: store subdevs in listBen Skeggs4-38/+31
This is somewhat nicer to read. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/subdev: remove nvkm_subdev.mutexBen Skeggs2-5/+0
There's not really any nice way to assign the lock classes when we split subdev indices into type+inst, and saves a few bytes in the structs when a subdev has no need for it. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/perfmon: use private spinlock to control exclusive access to perfmonBen Skeggs2-10/+14
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/fifo: private mutexBen Skeggs10-28/+30
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/disp: use private spinlock to control exclusive access to dispBen Skeggs2-10/+14
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/pmu: serialise send() with private mutexBen Skeggs3-3/+7
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/mmu: serialise mmu invalidations with private mutexBen Skeggs6-14/+15
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/ltc: serialise cbc operations with private mutexBen Skeggs2-2/+5
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/instmem: protect mm/lru with private mutexBen Skeggs5-29/+35
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/fb: protect vram mm with private mutexBen Skeggs2-5/+8
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/fb: protect comptags with private mutexBen Skeggs10-23/+29
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/engine: use refcount_t + private mutexBen Skeggs2-13/+25
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-09drm/ttm: move memory accounting into vmwgfx v4Christian König2-6/+2
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
2021-02-09drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_initYe Bin1-2/+0
Fix follow warning: drivers/gpu/drm/nouveau/nouveau_bios.c:2086:18: warning: variable ‘pdev’ set but not used [-Wunused-but-set-variable] struct pci_dev *pdev; ^~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210123013014.3815870-1-yebin10@huawei.com (cherry picked from commit 09b20988ff29eecc422484c266bee61b2fe58d8c) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-02-03drm/nouveau: fix dma syncing warning with debugging on.Dave Airlie1-6/+29
Since I wrote the below patch if you run a debug kernel you can a dma debug warning like: nouveau 0000:1f:00.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000016e012000] [size=4096 bytes] The old nouveau code wasn't consolidate the pages like the ttm code, but the dma-debug expects the sync code to give it the same base/range pairs as the allocator. Fix the nouveau sync code to consolidate pages before calling the sync code. Fixes: bd549d35b4be0 ("nouveau: use ttm populate mapping functions. (v2)") Reported-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/417588/
2021-02-03drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_initYe Bin1-2/+0
Fix follow warning: drivers/gpu/drm/nouveau/nouveau_bios.c:2086:18: warning: variable ‘pdev’ set but not used [-Wunused-but-set-variable] struct pci_dev *pdev; ^~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210123013014.3815870-1-yebin10@huawei.com
2021-01-29drm/nouveau/kms: handle mDP connectorsKarol Herbst2-0/+2
In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by: Mark Pearson <markpearson@lenovo.com> Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau: bail out of nouveau_channel_new if channel init failsFrantisek Hrbata1-0/+1
Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC ioctl. This was reported by trinity[1] fuzzer. [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 71.088928] #PF: supervisor read access in kernel mode [ 71.094059] #PF: error_code(0x0000) - not-present page [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0 [ 71.104842] Oops: 0000 [#1] SMP NOPTI [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2 [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014 [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau] [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41 [ 71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246 [ 71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf [ 71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160 [ 71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000 [ 71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08 [ 71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0 [ 71.188339] FS: 00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000 [ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0 [ 71.209297] Call Trace: [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm] [ 71.222421] drm_ioctl+0x211/0x3c0 [drm] [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau] [ 71.237285] ksys_ioctl+0x86/0xc0 [ 71.240595] __x64_sys_ioctl+0x16/0x20 [ 71.244340] do_syscall_64+0x4c/0x90 [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 71.253162] RIP: 0033:0x7fd925d4b88b [ 71.256731] Code: Bad RIP value. [ 71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b [ 71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003 [ 71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0 [ 71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620 [ 71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000 [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod [ 71.365269] CR2: 00000000000000a0 simplified reproducer ---------------------------------8<---------------------------------------- /* * gcc -o crashme crashme.c * ./crashme /dev/dri/renderD128 */ struct drm_nouveau_channel_alloc { uint32_t fb_ctxdma_handle; uint32_t tt_ctxdma_handle; int channel; uint32_t pushbuf_domains; /* Notifier memory */ uint32_t notifier_handle; /* DRM-enforced subchannel assignments */ struct { uint32_t handle; uint32_t grclass; } subchan[8]; uint32_t nr_subchan; }; static struct drm_nouveau_channel_alloc channel; int main(int argc, char *argv[]) { int fd; int rv; if (argc != 2) die("usage: %s <dev>", 0, argv[0]); if ((fd = open(argv[1], O_RDONLY)) == -1) die("open %s", errno, argv[1]); if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 && errno == EACCES) die("ioctl %s", errno, argv[1]); close(fd); printf("PASS\n"); return 0; } ---------------------------------8<---------------------------------------- [1] https://github.com/kernelslacker/trinity Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Frantisek Hrbata <frantisek@hrbata.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Fix locking for audio callbacksLyude Paul3-31/+43
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>
2021-01-29drm/nouveau/kms/nv50-: Use nouveau_encoder->crtc in get_eld callbackLyude Paul1-1/+1
drm_encoder->crtc is deprecated for atomic drivers, but nouveau_encoder->crtc is safe. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic stateLyude Paul1-21/+38
Despite being an atomic driver, nouveau has a lot of leftover code that relies on retrieving information regarding the new atomic state from members of drm_encoder and drm_crtc. The first field being used, drm_encoder.crtc, is deprecated for atomic drivers. The second field being used is drm_crtc.state, which is only really sensible to use outside of an atomic modeset. So, add some helpers to lookup the current crtc for a given outp from the atomic state. Then, convert most of the code in dispnv50/disp.c to use said new helper, along with the relevant DRM atomic helpers for retrieving the new encoder/crtc combinations for a new atomic state. Note that we don't get rid of the nouveau_encoder.crtc field entirely for three reasons: - Legacy modesetting for pre-nv50 still uses it - It doesn't cause any locking issues - We need it for the HDA callbacks, as grabbing atomic modesetting locks in those would be a mess. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Reverse args for nv50_outp_get_(old|new)_connector()Lyude Paul2-13/+8
Just to be more consistent with the order of args that DRM helpers like drm_atomic_get_new_crtc_state() use. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()Lyude Paul1-5/+4
I have a strange dejavu feeling that I tried to submit a patch for this in the past, but that it was rejected. I can't remember though, but I'm further convinced this patch is the right thing to do anyway. We label the to-be-committed head state in nv50_msto_atomic_enable() as armh. Normally armh implies a state which is currently armed in hardware. nv50_msto_atomic_enable() is called _after_ drm_atomic_swap_state() however, but before the commit tail ends, which means that said state is not actually armed on hardware. As well - take note that this is the same convention followed in all of the other atomic_enable() callbacks. So, let's correct this to asyh. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Rename encoder->atomic_(enable|disable) callbacksLyude Paul1-17/+16
No functional changes, just change the function names to match the callbacks they provide. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Remove (nv_encoder->crtc) checks in ->disable callbacksLyude Paul1-20/+17
Noticed these in both the disable (which we'll be getting rid of in a moment) and the atomic disable callbacks: both callback types check whether or not there's actually a CRTC assigned to the given encoder. However, as ->atomic_disable and ->disable will never be called without a CRTC assigned to the given encoder there's no point in this check. So just remove it. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/fifo/tu102: Turing channel preemption fixAlistair Popple1-41/+2
Previous hardware allowed a MMU fault to be generated by software to trigger a context switch for engine recovery. Turing has the capability to preempt all work from a specific runlist processor and removed the registers currently used for triggering MMU faults. Attempting to access these non-existent registers results in further errors, so use the runlist preemption register instead. Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/fifo/tu102: FIFO interrupt fixes for TuringAlistair Popple1-69/+9
Some of the low level FIFO interrupt status bits have changed for Turing. Update the handling of these to match the hardware. Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/fifo/tu102: Move Turing specific FIFO functionsAlistair Popple3-30/+511
Turing requires some changes to FIFO interrupt handling due to changes in HW register layout. It also requires some changes to implement robust channel (RC) recovery. This preparatory patch moves the functions requiring changes into nvkm/engine/fifo/tu102.c so they can be altered without affecting gk104 and other users. It should not introduce any functional changes. Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/mc/tu102: Remove Turing interrupt hackAlistair Popple3-20/+0
This is no longer needed now that tu102_mc_intr_stat has been updated to look at the correct top-level interrupt bits. Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/mc/tu102: Fix MMU fault interrupts on TuringAlistair Popple2-6/+122
Turing reports MMU fault interrupts via new top level interrupt registers. The old PMC MMU interrupt vector is not used by the HW. This means we can remap the new top-level MMU interrupt to the exisiting PMC MMU bit which simplifies the implementation until all interrupts are moved over to using the new top level registers. Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Log SOR/PIOR capsLyude Paul1-0/+10
Since I'm almost certain I didn't get capability checking right for pre-volta chipsets, let's start logging any caps we find to make things like this obvious in the future. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Don't call HEAD_SET_CRC_CONTROL in head907d_mode()Lyude Paul1-9/+2
This was a mistake that was present before, but never got noticed until we converted over to using nvidia's class headers for display programming. Luckily though it never caused any problems, since we always end up calling crc907d_set_src() after head907d_mode(). So, let's get rid of this. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: add module option to select EVO/NVD push buffer locationBen Skeggs1-1/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/gv100-: wait for less NVD pushbuf space for core updates ↵Ben Skeggs1-1/+1
without notify Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-gp1xx: wait for less EVO pushbuf space for core updates ↵Ben Skeggs1-1/+1
without notify Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursorsLyude Paul2-1/+31
While we do handle the additional cursor sizes introduced in NVE4, it looks like we accidentally broke this when converting over to use Nvidia's display headers. Since we now use NVVAL in dispnv50/head907d.c in order to format the value for the cursor layout and NVD9 only had one byte reserved vs. the 2 bytes reserved in later generations, we end up accidentally stripping the second bit in the cursor layout format parameter - causing us to set the wrong cursor size. This fixes that by adding our own curs_set hook for 917d which uses the NV917D headers. Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Cc: <stable@vger.kernel.org> # v5.9+ Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: ed0b86a90bf9 ("drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_curs_set()") Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-29drm/nouveau/kms/nv50-: Report max cursor size to userspaceLyude Paul1-0/+8
Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by: Lyude Paul <lyude@redhat.com> Tested-by: Simon Ser <contact@emersion.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 21:05:49 +0300